얼마 전에 새 프로젝트가 바로 분리의 전면과 후면 엔드에 종사하기 시작, 전송 된 후, 몇 시간 동안 사용, 놀라운 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