细说web开发里的cookie

　　做IT经常会有这种感觉，当初信誓旦旦的观点瞬间崩塌。前两天跟一个同事说到跨域的问题，继而谈到cookie，脑子马上出现了好多问号，于是翻阅资料才有了更深入的理解。cookie的存储位置
　　当年初识web开发，就知道cookie存在客户端，session存在服务端。那么cookie到底存在客户端的哪里，是硬盘里，内存里，浏览器里，document里，还是哪里？
　　首先思考一个问题，就是前面说的跨域问题。所谓跨域就是A站的页面不能随便请求B站的资源。这里其实有一个细节，请求都是客户端向服务端请求，严格来说跨域是响应到客户端的A站不能请求B站的服务端，而响应到客户端的B站就可以。这就奇怪了既然网页响应到客户端（即浏览器）便与服务端断开了连接，相互之间并没有瓜葛，怎么还能分得清A和B呢，难道html里偷偷藏了cookie在里面。这样才好解释每个请求里携带不同站点的cookie。事实上当然不是这样，html里除了我们自己写的那些标签再没有别的了。通过谷歌或火狐浏览器的设置里都能找到对应的存储cookie的位置，实际上cookie都是存在硬盘里的，安安静静的一个加密的文本文件。每次请求或者响应，浏览器都在根据站点与这个文本发生交互。所以，请暂时忘掉cookie藏在html里的想法。
　　cookie的调用
　　于是又回到了起初的那个问题，浏览器在请求时是怎么携带上对应的cookie呢？在深入思考前，咱们先做一个简单的模型。每个浏览器上渲染的页面都有地址吧，也就是url。比如说请求‘https：www。baidu。coms？ieUTF8wd火狐的cookie存在哪’这样一个地址，响应的html会被浏览器解析渲染出来，它的html内容与url自然是一一对应的，同样的，属于它的cookie内容也会被打上url的标识，就像xml解析一样。这样便好理解了，页面请求时，浏览器会根据它的url从cookie文件里查找对应的cookie内容一并放在headers（不同于html里的head标签）里发送给服务端。
　　前面说的是比较简单的模型，cookie与url一一对应。实际上，cookie与url的对应关系要复杂一些，这要涉及到cookie的两个属性，暂且卖个关子，下面的cookie属性再细说。cookie的属性
　　通常咱们使用cookie的属性，有name、value、maxAgeexpires，这三个分别表示cookie内容的名称，值还有过期时间，不常用的属性也有三个，secure、comment、version分别表示安全传输协议、说明、规范版本。下面咱们要说到的是另两个不太常用但是却很重要的属性，即domain和path。
　　domain和path分别代表了cookie键值所属的站点和位置。举例来说，全村人把所有家伙什拿出放在一堆儿。而件家伙什都有各自的所属，有的呢只能被张三家使用，有的呢只要姓李就能使用，有的呢只能给王五的媳妇用。下面咱们就拿实例来说了，拿前面提到的url来说，打开谷歌浏览器访问，并打开开发工具里的application下的cookie查看。
　　如上图，红标1的domain是www。baidu。com，那么这条cookie就会被www。baidu。com下的页面调起使用；红标2的domain是。baidu。com，那么这条cookie就会被www。baidu。com、live。baidu。com等。baidu。com结尾的页面调起使用。再拓展一下，如果domain是。www。baidu。com，那么a。www。baidu。com当然也能调用，单点登录就是这么实现的。
　　domain搞明白了再说path，通常这个属性值都设为也就是根目录，表示这个cookie能被对应domain下所有页面调用，但是如果设置二级目录，比如api，那么必须是这个domain下的api目录才能使用。打个比方，一个庭院，如果院子里放着一个篮球，厨房里放着一个炒锅，卧室放着一个枕头。只要你进入这个庭院就能得到篮球，但是要得到炒锅就要进入厨房，要得到枕头就必须进入卧室。还有，如果你进入卧室，你不仅能拿到枕头，大院里的篮球也能拿到。依此类推，如果厨房的米柜里放着大米，要得到大米不仅要进入厨房还要打开米柜。总而言之，页面能取得当前目录及父级，父级的父级直到根目录的cookie。
　　说完了这些参数，cookie的调用就好理解了，也许每个浏览器有自己的寻址逻辑，但是大致思路是一致的。当向服务端请求时，浏览器会根据当前页面的url在cookie文件进行查找，首先根据domain查找，然后再根据path逐层查找，然后把所有合格的cookie带上传送给服务端。cookie的设置
　　cookie存储在客户端，正常情况下cookie内容是由服务端控制的。这样才能实现登录或者其他业务。这就要谈到一个问题，服务端是怎么控制客户端的cookie的。
　　其实很简单，浏览器向服务端请求时，服务端会在响应的header头里携带setcookie指令告诉浏览器，设置cookie的所有属性。并不是每次请求浏览器都会对cookie文件修改，只有收到这种setcookie指令时才会修改。比如我已经登录了百度贴吧，会写入。ba
　　idu。com一些键值记录登录状态，再访问百度地图时就不会再有记录登录信息的setcookie了。
　　前面说的是正常情况，当然就会有其他情况。比如js里执行个脚本document。cookieusernameDarren；path；〔domain。csdn。net〕（http：domain3D。csdn。net），可以轻意的修改cookie，或者在浏览器的开发工具里直接修改，还有很多的第三方插件都很容易做到。这样说来，cookie信不过。但是也没有更信得过的好办法了。说直白点，cookie是你存放物品的回执单，一旦被别人拿到就能把你的物品取走。甚至cookie比回执单更不安全，因为它可以复制，无限复制。咱们能做的还是自己小心。cookie的祸端
　　许多人利用cookie作恶，最典型的是csrf攻击。就好像盗取了你的微信号然后给你家人打电话要钱。具体怎么实现呢，我举两个例子。
　　某个博客网站，删除文章只需要调用一个地址，abc。blog。comarticldelete234。正常情况下，服务端要验证是否是本人删除。非登录状态或者非本人文章是验证不通过的。但是，有这样一种场景。你在登录博客之后，浏览其它网站时，别人把这个链接藏在某个按钮或图片里，一旦你打开这个链接，浏览器首先会根据网址找到你存在电脑上的cookie信息发送给服务端，服务端会认为是本人所为，自然而然执行删除。
　　当然了，删除和修改的请求一般不会用get方法。那么我们再把黑客强大一些，即使是post请求，黑客用ajax模拟出了删除脚本，然后以评论或者其它方法写进了网站数据。当其它用户登录并打开了这个页面，就会启动删除脚本，同样会带上用户的cookie发送到服务端，服务端也同样会认为是本人所为，执行操作。
　　当然，网站能被植入脚本，网站开发要背锅。cookie的拓展seesion
　　既然cookie在客户端被随便修改，那么session在服务端是不是更安全一些呢。我先说结果，就安全而言两者是一模一样的。因为session内容虽然存在服务器上，但是也是通过一个namePHPSESSID的cookie来连接的。只要别人拿了这个cookie，你用seesion在服务器上存了多少信息，也能给你挖出来。session是不能脱离cookie存在的。token
　　token是前后分离后，用来跟服务端交互的手段，用来标识用户。曾经我以为token放在请求body里的参数，很容易被窃取，非常不安全。现在想想好天真，不管用cookie还是token都是秃子头上的虱子明摆着。
　　好了，今天就说到这了。web开发经过几代大牛的耕耘才发展到现在，实属不易。但是仍然还有很多的路要走。