しばらく前に新しいプロジェクトがちょうど分離の前後端に従事し始め、転送された、その後、いくつかの時間のために使用され、素晴らしいVUEを使用し、操作のjQueryのDOMを持つノーリターンの時代の前に自分自身を発見。大幅に開発作業を簡素化し、このようなものは本当に速いハードウェアは、開発者が注射を達成するために、ビジネスに集中できるように、ロジックからスピンオフDOMを提示されます。しかし、分離ページの終了前と後のような典型的なクロスドメインの問題などの問題、一連のをもたらします。だから、クロスドメインソリューションのための研究の機会を活用し、便利なセッションとトークンの間に私のポイントを下にスライドさせ、より多くの透明性を学んだファジーてきました。
クロスドメイン（ソース）
まずは、クロスドメインをサポートしていないサイトは、エラーとして報告されます場合は、クロスドメインで何を見てみましょう。
以下に示すように、ページは、我々が見ることができる開かれたとき、ヘッダーで要求元のフィールドが存在し、フィールドの値は、我々は、このページを理解することができます文字通りの意味から現在のウィンドウには、また、ソースと呼ばれるドメインを表し、ソース。
あなたのリクエストサーバを、要求を受け入れることができ、その上、ドメイン、値が「*」は、任意のドメインの受け入れを示している場合は、この値は、複数のドメインを含むことができる：最初のリターンアクセス制御が可能原産のフィールドが示すあります。
たとえば、あなたは駅Aのページを開き、局Aは、サーバステーションBにページ要求を送信し、要求が原点ステーションのヘッドドメイン名フィールドに置かれます、駅Bは、原点設定後に戻って自分自身へのリクエストを受信しますアクセス制御 - 許可原産のフィールドを比較し、ブラウザ同一生成元ポリシーに応じて、要求が傍受され、何のドメインに駅を認めなかった（さらに簡単ではなく、ここで非単純な要求要求、同じ原理に分け要求）を繰り返すと、最初のメッセージがブラウザに返される戻ります。最も当面の問題の前端と後端とを分離するフィールドで同じではない、最も単純な、粗溶液をフィルタの後端部にアクセス制御可能由来のフィールドの値を設定することで、クロスドメインの問題を解決することができます。
二、セッション
基于session的校验方式，流程其实很简单，用户第一次登陆网站的时候，在服务端创立对应的session对象，该session对象通过sessionid来做唯一识别，并将该id返回给浏览器，浏览器拿到id后将其保存在cookies中。之后用户再次访问此域的页面时，浏览器可以随时从cookie中取sessionid，而不需要做额外的校验，只要在发送请求时再次提供id，服务器便能根据id在内存中找到对应用户的身份信息。
但是session有两个弊端，第一个就是当用户数量越来越多，内存中保存的用户信息也越来越大，十分占据内存；第二个是若该域支持第三方网站发送请求，也就是支持任何其他网站发送跨域请求时，会产生csrf漏洞。
所谓csrf漏洞其实很好理解，例如有一个支持跨域的银行网站，该网站有一个转账链接:http://xxxx.com?account=alice&count=1000&reciver=jack，当支持跨域时，这个链接可以嵌在任何页面，而且不会因为跨域问题被拦截。此时我们的主人公alice登陆了银行网站，此时session创建成功，并且将sessionid保存在cookies中，但这时候不小心打开了一个恶意网站，这个网站中嵌入了上述的转账链接并且触发了链接，然后浏览器会自动将携带cookie中的信息发送到后台做身份校验，后台校验通过，于是alice的1000块就这样转给jack。
三、Token
于是我们在想，既然使用cookie中的sesssionID，有风险，那我们能不能不用cookie？于是token就产生了（当然token只是解决csrf攻击的手段之一）。在了解token之前，我们需要先简单了解一下加密算法，一般最常用的加密算法为sha256。该算法有一个密码，我们称之为密钥，用户信息+密钥在经过该算法计算后，会得出token。该算法原理其实和我们以前学过的微分方程有点像，每组三个解，其中有一个是公共解（通解），这个公共解就是密钥（所以sha256也是可以根据多组解计算之后破译的，因此我们需要经常更换密钥）。另外两个解，一个是用户的身份信息，另一个就是token了，后面再次请求后台时都需要带上这两个东西。即便用户在客户端擅自修改了自己的身份信息也不怕，因为修改后的身份信息传送给后台后，后台会再次用sha256计算一次，修改后的用户信息+密钥算出的token与原token不一致，请求不通过。
token在服务端通过上述算法生成之后，连同其中的用户信息一起发送给浏览器，然后由浏览器将其保存在窗口内存中，每次点击转账链接时只需将token和自己的信息也一起发送给服务端（http://xxxx.com?account=alice&count=1000&reciver=jack&token=123456）这样即使恶意网站内嵌了转账链接触发了也不怕，因为恶意网站无法跨窗口拿到自己的token和用户信息（而之前使用session时，转账链接会自动将cookie中的sessionid发送给后台完成身份校验）。
参考资料：http://www.ruanyifeng.com/blog/2016/04/cors.html