商业源码 cookies是什么东西？干什么用的？
使用COOKIE时不能设置了COOKIE后就直接调用，COOKIE是在访问页面时客户端浏览器自动发送给服务器的，而setcookie是给浏览器发送头后，浏览器保存的数据，不可一次性操作。
你可以写两个页面试试，一个 setcookie ，另一个用 print_r( $_COOKIE ); 看看是否显示。
1。 Cookie是一种发送到客户浏览器的文本串句柄，并保存在客户机硬盘上，
可以用来在某个Web站点会话之间持久地保持数据。Request和Response对象都有
一组Cookie。Requestcookie集合是一系列Cookie，从客户端与HTTP Request一
起发送到Web服务器。反过来，如果你希望把Cookie发送到客户机，就可以使用R
esponsecookie
1、ExpiresAbsolute属性
该属性可以赋一个日期，过了这个日期Cookie就不能再被使用了。通过给Ex
pires属性赋一个过期的日期，就可以删除Cookie。如：
<%Responsecookies("passtime")expiresAbsolute="1/1/99"%>
2、Domain属性
该属性定义Cookie要传送的唯一域。如：Cookie只传送给Microsoft的人，
则可以使用以下代码。
<%ResponseCookies("domain")Domain="wwwmicrosoftcom"%>
3、ASP用来写入Cookie即向客户机发送Cookie的语法如下：
ResponseCookie("Cookie名")[("键名")属性]=内容
如果某个ASP文件要创建一个Cookie，则下面的代码可以放在ASP文件的第一
个<html>之前，以避免产生错误
<%ResponseCookies("CookieName")="NewCookie" %>
<html>
</html>
4、同样ASP用Request对象的Cookies集合来读取Cookie，如：
<%Responsewrite RequestCookies("CookieName")%>
下面以一个完整的例子来说明Cookie：
<%
dim Num
Num=RequestCookies("Visit_num")
if Num>0 then
Num=Num+1
Responsewrite "您已是第" & Num & "次访问本站点了。"
else
Responsewrite "欢迎您首次访问本站。"
Num=1
end if
ResponseCookies("Visit_num")=Num
%>
在该例子中，首先读取Cookies变量Visit_num，看用户端计算机是否保存有
Cookies变量。如果有该变量，则说明用户已经访问过该页面，同时输入出访问
次数。如果用户是首次访问该页面，则其计算机内不会有Cookies变量，程序会
显示“欢迎”字样，然后将Cookies变量Visit_num存到用户计算机中，以便该用
户下一次访问该页面时给出“访问的次数”信息。
5、Cookie字典
有时在一个页面中可能需要定义很多个Cookies变量，为了更好地管理它，
在Cookies组件中常引入一人的概念“子键”。引用它的语法如下：
RequestCookies("变更名")("子键名")
如下面的Cookie创建一个名为"Dictionary"的字典，其中保存了三个键值：
<%
ResponseCookie("info")("Myname")="jeff"
ResponseCookie("info")("Gender")="male"
ResponseCookie("info")("Myheight")="172"
%>
事实上客户机上的Cookie字典是以字符串的形式存在：
info=Myname=jeff&Gender=male&Myheight=172
如果用户没有指定“子键”名而直接引用Cookies变量，将会返回一个包含
所有的“子键”名及值的字符串。例如上面这个例子包含三个“子键”："Mynam
e"、"Gender"和"Myheight"，当用户没有指定其“子键”而直接通过RequestCo
okies("info")来引用时，则会得到下列字符串：
info=Myname=jeff&Gender=male&Myheight=172
如果要把Cookie中读取的所有数据，可以用下面的代码得到：
<%For each cookie in RequestCookies
if Not cookieHasKeys then
Responsewrite cookie & "=" & RequestCookies(cookie)
Else
for each key in RequestCookies(cookie)
Responsewrite cookie&"("&key&")"&"="&
RequestCookies(cookie)(key)
next
end if
next
%>
2。Session其实指的就是访问者从到达某个特定主页到离开为止的那段时间。每
一访问者都会单独获得一个Session。在Web应用程序中，当一个用户访问该应用
时，Session类型的变量可以供这个用户在该Web应用的所有页面中共享数据；如
果另一个用户也同时访问该Web应用，他也拥有自己的Session变量，但两个用户
之间无法通过Session变量共享信息，而Application类型的变更则可以实现站点
多个用户之间在所有页面中共享信息。
1、SessionID属性
该属性返回当前会话的唯一标志，为每一个Session分配不同的编号。
我曾在开发过程中就遇到对用户的控制问题。它要实现的功能就是，针对某
个网站的一个模块，当一个会员登录后正在看此模块时，另一个人用同样的会员
名登录，就不能浏览这个模块。也就是说一个会员名同时只能一个人浏览此模块
。我通过用会员名（假设为UserID，唯一）和SessionID来实现了控制。当会员
登录时，给这个会员一个Session记录登录状态如：Session("Status")="Logged
"，同时把这个会员的SessionSessionID写入数据库。当他要浏览此模块时，先
判断其是否登录，若已经登录再判断它的SessionID是否与数据库记录的相同，
如果不同则不能访问。这样，当另一个用户用相同的会员名登录时，那么数据库
中记录的就是新的SessionID，前者访问此模块时就不能通过检查。这就实现了
一个会员名同时只能一个人浏览某个模块。这个功能在一些收费网站有很有特别
作用，它防止了一个会员名给多个人浏览的问题，为公司保障了利益。
2、TimeOut属性
该属性用来定义用户Session对象的时限。如果用户在规定的时间内没有刷
新网页，则Session对象就会终止。一般默认为20分钟。
3、Abandon方法
该方法是Session对象的唯一方法，可以清除Session对象，用来消除用户的
Session对象并释放其所占的资源。如： <% SessionAbandon %>
4、Session_OnStart和Session_OnEnd事件
和Application一样，当对象的例程每一次启动时触发Session_OnStart事件
，然后运行Session_Onstart事件的处理过程。也就是说，当服务器接收到应用
程序中的URL的HTTP请求时，触发此事件，并建立一个Session对象。同理，这个
事件也必须定在Globalasa文件中。
当调用SessionAbandon方法时或者在TimeOut的时间内没有刷新，这会触发
Session_OnEnd事件，然后执行里面的脚本。Session变量与特定的用户相联系，
针对某一个用户赋值的Session变量是和其他用户的Session变量完全独立的，不
会存在相互影响。
Session应用一列：
与Application一样，一个被定义为Session类型的数组只能将整个数组作为
一个对象，用户不能直接改变Session数组中某个元素的值。为了创建一个Sessi
on数组，需先定义一个普通的数组，并对它的每一个元素赋初值，最后把它定义
为一个Session数组。如：
<%
dim array()
array=array("jeff","zhu","male")
Session("info")=array
Responsewrite Session("info")(0) &"-"
Responsewrite Session("info")(1) &"-"
Responsewrite Session("info")(2) &"<br>"
%>
<hr>
<%
array(0)="jun"
array(1)="li"
array(2)="female"
Session("info")=array
Responsewrite Session("info")(0) & "-"
Responsewrite Session("info")(1) & "-"
Responsewrite Session("info")(2) & "<br>"
%>
以上这段程序输出结果是：
jeff-zhu-male
_____________
jun-li-female
Session是怎样工作的？
Session其实是利用Cookie进行信息处理的，（参见后面有关Cookies的介绍），
当用户首先进行了请求后，服务端就在用户浏览器上创建了一个Cookie，当这个
Session结束时，其实就是意味着这个Cookie就过期了。
为这个用户创建的Cookie的名称是ASPSESSIONID。这个Cookie的唯一目的就是为
每一个用户提供不同的身份认证。
注：如果你对名字是ASPSESSIONID的COOKIE感到好奇，你可以利用ServerVariab
les集合的COOKIE Header来接受这个信息，参看下面这个脚本：
<%=RequestServerVariables(“HTTP COOKIE”) %>
你可以刷新不止一次而显示结果依然不变。如果希望对ServerVariables集合有
更多了解，那么请去看第14章。
Session变量自己不会存在用户浏览器上。不过，ASPSESSIONID这个cookie需要
使用session变量。server使用ASPSESSIONID
cookie来将特定的用户和特定的session信息联系起来。没有cookie的话，Serve
r就不会了解到每一个特定用户在网站中移动的信息。
利用SessionID变量存储ASPSESSIONID
cookie和直接对名为ASPSESSIONID的cookie赋值有很大不同。微软利用了一个复
杂的数学算法对SessionID进行了加密措施，以防止黑客猜测出SessionID的值并
且依据这个获得不该获得的身份或权限。
注：你可以用两种方法屏蔽掉SessionID，一种是将全站进行屏蔽，另外一种是
将一个单独Active Server Page进行相应屏蔽。
如果想要将整个站点的Session操作进行屏蔽，你可以使用Internet Service
Manager。从Application设置对话框，点击Active Server
Pages表并且取消对Enable Session State选项的选择。
你还可以在特定的Active Server Page的首行加入使之屏蔽的语句来进行这种操
作。
<% EnableSessionState=False %>
由于Session对象使用了Cookies，那么它的兼容性就受到了限制，一些老的浏览
器显然是不行的，新的浏览器象是NetScape40也提供了屏蔽Cookie的选项。
这样就出了问题、由于Cookie不能适用于所有浏览器，那么在建站时你就必须注
意了，如果你的网站定位于大众通用，就必须考虑各种不同的用户情况。不过现
在确实有可以替代的方法，有些取代Cookies来进行身份认证的方法将在后面的
Cookies是一种能够让网站服务器把少量数据储存到客户端的硬盘或内存，或是从客户端的硬盘读取数据的一种技术。Cookies是当你浏览某网站时，由Web服务器置于你硬盘上的一个非常小的文本文件，它可以记录你的用户ID、密码、浏览过的网页、停留的时间等信息。当你再次来到该网站时，网站通过读取Cookies，得知你的相关信息，就可以做出相应的动作，如在页面显示欢迎你的标语，或者让你不用输入ID、密码就直接登录等等。
从本质上讲，它可以看作是你的身份证。但Cookies不能作为代码执行，也不会传送病毒，且为你所专有，并只能由提供它的服务器来读取。保存的信息片断以“名/值”对(name-value pairs)的形式储存，一个“名/值”对仅仅是一条命名的数据。一个网站只能取得它放在你的电脑中的信息，它无法从其它的Cookies文件中取得信息，也无法得到你的电脑上的其它任何东西。
Cookies中的内容大多数经过了加密处理，因此一般用户看来只是一些毫无意义的字母数字组合，只有服务器的CGI处理程序才知道它们真正的含义。
由于Cookies是我们浏览的网站传输到用户计算机硬盘中的文本文件或内存中的数据，因此它在硬盘中存放的位置与使用的操作系统和浏览器密切相关。在Windows 9X系统计算机中，Cookies文件的存放位置为C:WindowsCookies，在Windows NT/2000/XP的计算机中，Cookies文件的存放位置为Cocuments and Settings用户名Cookies。
硬盘中的Cookies文件可以被Web浏览器读取，它的命令格式为：用户名@网站地址[数字]txt。如笔者计算机中的一个Cookies文件名为：ch@163[1]txt。要注意的是：硬盘中的Cookies属于文本文件，不是程序。
Cookies的设置
你可以在IE的“工具/Internet选项”的“常规”选项卡中，选择“设置/查看文件”，查看所有保存到你电脑里的Cookies。这些文件通常是以user@domain格式命名的，user是你的本地用户名，domain是所访问的网站的域名。如果你使用NetsCape浏览器，则存放在“CROGRAMFILESNETS- CAPEUSERS”里面，与IE不同的是，NETSCAPE是使用一个Cookie文件记录所有网站的Cookies。
我们可对Cookie进行适当设置：打开“工具/Internet选项”中的“隐私”选项卡（注意该设置只在IE60中存在，其他版本IE可以单击“工具/Internet选项”“安全”标签中的“自定义级别”按钮，进行简单调整），调整Cookie的安全级别。通常情况，可以调整到“中高”或者“高”的位置。多数的论坛站点需要使用Cookie信息，如果你从来不去这些地方，可以将安全级调到“阻止所有Cookies”;如果只是为了禁止个别网站的Cookie，可以单击“编辑”按钮，将要屏蔽的网站添加到列表中。在“高级”按钮选项中，你可以对第一方Cookie和第三方的Cookie进行设置，第一方Cookie是你正在浏览的网站的Cookie，第三方Cookie是非正在浏览的网站发给你的Cookie，通常要对第三方Cookie选择“拒绝”。你如果需要保存Cookie，可以使用IE的“导入导出”功能，打开“文件/导入导出”，按提示操作即可。
Cookies的写入与读取
Cookies集合是附属于Response对象及Request对象的数据集合，使用时需要在前面加上Response或Request。
用于给客户机发送Cookies的语法通常为：
当给不存在的Cookies集合设置时，就会在客户机创建，如果该Cookies己存在，则会被代替。由于Cookies是作为HTTP传输的头信息的一部分发给客户机的，所以向客户机发送Cookies的代码一般放在发送给浏览器的HTML文件的标记之前。
如果用户要读取Cookies，则必须使用Request对象的Cookies集合，其使用方法是：
需要注意的是，只有在服务器未被下载任何数据给浏览器前，浏览器才能与Server进行Cookies集合的数据交换，一旦浏览器开始接收Server所下载的数据，Cookies的数据交换则停止，为了避免错误，要在程序和前面加上responseBuffer=True。
Cookies的应用
几乎所有的网站设计者在进行网站设计时都使用了Cookie，因为他们都想给浏览网站的用户提供一个更友好的、人文化的浏览环境，同时也能更加准确地收集访问者的信息。
网站浏览人数管理
由于代理服务器、缓存等的使用，唯一能帮助网站精确统计来访人数的方法就是为每个访问者建立一个唯一的ID。使用Cookie，网站可以完成以下工作：测定多少人访问过；测定访问者中有多少是新用户（即第一次来访），多少是老用户；测定一个用户多久访问一次网站。
通常情况下，网站设计者是借助后台数据库来实现以上目的的。当用户第一次访问该网站时，网站在数据库中建立一个新的ID，并把ID通过Cookie传送给用户。用户再次来访时，网站把该用户ID对应的计数器加1，得到用户的来访次数或判断用户是新用户还是老用户。
按照用户的喜好定制网页外观
有的网站设计者，为用户提供了改变网页内容、布局和颜色的权力，允许用户输入自己的信息，然后通过这些信息对网站的一些参数进行修改，以定制网页的外观。
在电子商务站点中实现诸如“购物篮”等功能
可以使用Cookie记录用户的ID，这样当你往“购物篮”中放了新东西时，网站就能记录下来，并在网站的数据库里对应着你的ID记录当你“买单”时，网站通过ID检索数据库中你的所有选择就能知道你的“购物篮”里有些什么。
在一般的事例中，网站的数据库能够保存的有你所选择的内容、你浏览过的网页、你在表单里填写的信息等；而包含有你的唯一ID的Cookie则保存在你的电脑里。
Cookies的缺陷
Cookie虽然被广泛的应用，并能做到一些使用其它技术不可能实现的功能。但也存在一些不够完美的方面，给应用带来不便。
多人共用一台电脑的问题
任何公共场合的电脑或者许多在办公室或家里使用的电脑，都会同时被两个以上的人使用。这样，当你用它在网上超市购物时，网上超市或网站会在这台机器上留下一个Cookie，将来也许就会有某个人试图使用你的账户购物，带来了不安全的可能。当然，在一些使用多用户操作系统如Windows NT或UNIX的电脑上，这并不会成为一个问题。因为在多用户操作系统下不同的账户的Cookie分别放在不同的地方。
Cookies被删除时
假如你的浏览器不能正常工作，你可能会删除电脑上所有的临时Internet文件。然而，一旦这样操作以后，你就会丢掉所有的Cookies文件。当你再次访问一个网站时，网站会认为你是一位新用户并分配给你一个新的用户ID以及一个新的Cookie。结果将会造成网站统计的新老用户比发生偏差，而你也难以恢复过去保存的参数选择。
一人使用多台电脑时
有的人一天之中经常使用一台以上的电脑。例如在办公室里有一台电脑、家里有一台、还有移动办公用的笔记本电脑。除非网站使用了特别的技术来解决这一问题，否则，你将会有三个不同的Cookies文件在这三台机器上，而在三台机器上访问过的任何网站都将会把你看成三个不同的用户。
防范Cookies泄密
想知道你访问的网站是否在你的硬盘或内存中写入了Cookies信息吗？只需执行下面的操作步骤，就可以了解和控制你正在访问的网站的Cookies信息。
步骤一 点击IE窗口中的“工具” “In-ernet选项”，打开“Internet选项”设置窗口；
步骤二 点击“Internet选项”设置窗口中的“安全”标签，然后再点击“自定义级别”按钮，进入“安全设置”窗口；
步骤三 找到“安全设置”窗口中的“Cookies”设置项。“Cookies”设置项下有两个分选项，其中“允许使用存储在您计算机上的Cookies”是针对存储在用户计算机硬盘中的Cookies文件；“允许使用每个对话Cookies（未存储）”是针对存储在用户计算机内存中的Cookies信息。存储在硬盘中的Cookies文件是永久存在的，而存储在内存中的Cookies信息是临时的。要想IE在即将接收来自Web站点的所有Cookies时进行提示，可分别选择上面两个分选项中的“提示”项。当然，你也可以选择“启用”，允许IE接受所有的Cookies信息（这也是IE的默认选项）；选择“禁止”，则是不允许Web站点将Cookies存储到您的计算机上，而且Web站点也不能读取你计算机中已有的Cookies。
IE60提供了更为可靠的个人隐私及安全保护措施，可以让用户来控制浏览器向外发送信息的多少。在“Internet 选项”窗口中新增了“隐私”选项卡（图1），用户可以在其中直接设置浏览时的隐私级别，按需要控制其他站点对自己电脑所使用的Cookies。如果我们正在浏览的站点使用了Cookie，那么在浏览器状态栏中会有一个**惊叹号的标记，双击后可打开“隐私报告”对话框，用户可以在其中查看具体的隐私策略，还可直接点击“设置”按钮后在上述“隐私”选项卡中调节安全隐私级别。
在“常规”选项卡中还增加了“删除Cookies”按钮（图2），方便用户直接清除本机上的Cookies。另外，在“工具” “选项” “高级”选项卡中也增加了一些进一步提高安全性的选项（如关闭浏览器时清空Internet临时文件）。其实，如何更好地保护个人隐私和安全是微软下一代“NET”战略软件中的关键技术，现在IE60已经尝试着迈出了第一步。
另外，由于Cookies的信息并不都是以文件形式存放在计算机里，还有部分信息保存在内存里。比如你在浏览网站的时候，Web服务器会自动在内存中生成Cookie，当你关闭IE浏览器的时候又自动把Cookie删除，那样上面介绍的两种方法就起不了作用，我们需要借助注册表编辑器来修改系统设置。要注意的是，修改注册表前请作备份，以便出现问题后能顺利恢复。
运行Regedit，找到如下键值：HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInternet SettingsCacheSpecial PathsCookies，这是Cookies在内存中的键值，把这个键值删除。至此Cookies无论以什么形式存在，我们都不用再害怕了。
最后有必要说明的一点是：杜绝Cookies虽然可以增强你电脑的信息安全程度，但这样做同样会有一些弊端。比如在一些需要Cookies支持的网页上，会发生一些莫名其妙的错误，典型的例子就是你以后不能使用某些网站的免费信箱了。
Cookies欺骗
通过分析Cookie的格式，我们知道，最后两项中分别是它的URL路径和域名，服务器对Cookie的识别靠的就是这两个参数。正常情况下，我们要浏览一个网站时输入的URL便是它的域名，需要经过域名管理系统DNS将其转化为IP地址后进行连接。若能在DNS上进行一些设置，把目标域名的IP地址对应到其它站点上，我们便可以非法访问目标站点的Cookie了。
要进行Cookies欺骗，其实很简单。比如在Win9X下的安装目录下，有一名为hostssam的文件，以文本方式打开后会看到这样的格式：
127001 localhost
经过设置，便可以实现域名解析的本地化，只需将IP和域名依上面的格式添加到文件中并另存为hosts即可。hosts文件实际上可以看成一个本机的DNS系统，它可以负责把域名解释成IP地址，它的优先权比DNS服务器要高，它的具体实现是TCP/IP协议中的一部分。
比如我们要读取的目标站点 wwwabccom 所生成的Cookies信息，可以借助wwwdefcom（自己的站点）。在wwwdefcom 存放用来进行欺骗所需的文件，通过它读取和修改对方的Cookie。
步骤一 ping出wwwdefcom 的IP地址：
ping wwwdefcom
Reply from 19216801: bytes=32 time=20ms TTL=244
然后修改hostssam文件如下：
19216801 wwwabccom
并保存为hosts文件。
步骤二 读取Cookies信息：
将用来读取Cookie的页面传至wwwdefcom ，此时连上wwwabccom，由于我们进行本机DNS域名解析的修改，这时网络连接的并不是wwwabccom，而是wwwdefcom 。
这样wwwabccom设在本地的Cookie便可被读出。
步骤三 同样道理，你可对读出的数据进行修改，并可将修改后的信息写入Cookie中。修改完毕后，删掉hosts文件，再重新进入wwwabccom，此时所使用的Cookies数据就是你制定的数据。
总之，在某种程度上虽然可以实现Cookies的欺骗，给网络应用带来不安全的因素，但Cookies文件本身并不会造成用户隐私的泄露，也不会给黑客提供木马程序的载体，只要合理使用，它们会给网站管理员进行网站的维护和管理以及广大用户的使用都带来便利。
Cookies集合具有以下几种属性
1Expires属性：此属性用来给Cookies设置一个期限，在期限内只要打开网页就可以调用被保存的Cookies，如果过了此期限Cookies就自动被删除。如：
设定Cookies的有效期到2004年4月1日，到时将自动删除。如果一个Cookies没有设定有效期，则其生命周期从打开浏览器开始，到关闭浏览器结束，每次运行后生命周期将结束，下次运行将重新开始。
2Domain属性：这个属性定义了Cookies传送数据的唯一性。若只将某Cookies传送给搜狐主页时，则可使用如下代码：
3Path属性：定义了Cookies只发给指定的路径请求，如果Path属性没有被设置，则使用应用软件的缺省路径。
4Srcure属性：指定Cookies能否被用户读取。
5Haskeys属性：如果所请求的Cookies是一个具有多个键值的Cookies字典，则返回True，它是一个只读属性。
cookie 是一个文件，存放在本地，chrome浏览器F12后的Application下可查看cookies。由服务器生成，故Response Headers中会存在Set-Cookie字段。
session 是为了保持服务器与客户端的会话状态，在用户登录后，服务器端生成一个sessionID传给客户端；之后的每次会话，客户端只需要传这个sessionID即可不用重新登录，保持在线状态。故服务器端需要保存所有在线的sessionID，从而影响服务器性能！ sessionID是存在cookie中的。
token 是为了解决服务器压力，用户登录成功后，服务器端生产token（钥匙和锁）通过 cookie或请求头的方式 传给客户端，再次请求时带上token即可，无状态（服务端通过算法验证钥匙和锁是否正确）。
总之 ，就是两种鉴权方式，通过sessionID或者token，服务器来判断是否是某用户登录后的其他请求。
其他：
2、一个用户在一次会话（打开浏览器，访问服务器，直到浏览器关闭，称为一次会话，严格的说，一次会话应该是依赖 session 的生成机制）上就是一个session_id。
3、每次登录时，总会产生一个token或者sessionID，生成这个的目的是为了每次操作其他接口的时候，会判断当前用户是否登录。
1）cookie的处理
准备：两个接口：一个登录、一个充值
登录接口
充值接口：会失败
1、添加：HTTPCookie管理器，放到最上面。
2、再次运行：就会充值成功。
登录时会有set_Cookie存在
1、添加后置处理器>>>正则表达式提取器
设置：
2、添加：调试取样器
运行结果：已经拿到cookie
3、添加：右击线程组>>添加>>配置元件>>HTTPCookie管理器
设置：
4、添加：JSESSIONID：${正则表达式提取器提取到的变量名}
域：
路径：
5、查看运行结果：
2）token的处理
查询用户信息需要先登录，在查询用户信息的时候需要携带token。
1、在登录接口下面使用正则表达式提取器获取token
登录接口响应数据中返回token。
配置提取器：
2、添加：调试取样器，运行后查看是否可以获取到
3、添加HTTP信息头管理器
运用相关资料
本文你将看到：
「前端存储」这就涉及到一发、一存、一带，发好办，登陆接口直接返回给前端，存储就需要前端想办法了。
前端的存储方式有很多。
有，cookie。cookie 也是前端存储的一种，但相比于 localStorage 等其他方式，借助 HTTP 头、浏览器能力，cookie 可以做到前端无感知。一般过程是这样的：
「配置：Domain / Path」
cookie 是要限制::「空间范围」::的，通过 Domain（域）/ Path（路径）两级。
「配置：Expires / Max-Age」
cookie 还可以限制::「时间范围」::，通过 Expires、Max-Age 中的一种。
「配置：Secure / HttpOnly」
cookie 可以限制::「使用方式」::。
「HTTP 头对 cookie 的读写」回过头来，HTTP 是如何写入和传递 cookie 及其配置的呢？HTTP 返回的一个 Set-Cookie 头用于向浏览器写入「一条（且只能是一条）」cookie，格式为 cookie 键值 + 配置键值。例如：
那我想一次多 set 几个 cookie 怎么办？多给几个 Set-Cookie 头（一次 HTTP 请求中允许重复）
HTTP 请求的 Cookie 头用于浏览器把符合当前「空间、时间、使用方式」配置的所有 cookie 一并发给服务端。因为由浏览器做了筛选判断，就不需要归还配置内容了，只要发送键值就可以。
「前端对 cookie 的读写」前端可以自己创建 cookie，如果服务端创建的 cookie 没加HttpOnly，那恭喜你也可以修改他给的 cookie。调用documentcookie可以创建、修改 cookie，和 HTTP 一样，一次documentcookie能且只能操作一个 cookie。
调用documentcookie也可以读到 cookie，也和 HTTP 一样，能读到所有的非HttpOnly cookie。
现在回想下，你刷卡的时候发生了什么？
这种操作，在前后端鉴权系统中，叫 session。典型的 session 登陆/验证流程：
「Session 的存储方式」显然，服务端只是给 cookie 一个 sessionId，而 session 的具体内容（可能包含用户信息、session 状态等），要自己存一下。存储的方式有几种：
「Session 的过期和销毁」很简单，只要把存储的 session 数据销毁就可以。「Session 的分布式问题」通常服务端是集群，而用户请求过来会走一次负载均衡，不一定打到哪台机器上。那一旦用户后续接口请求到的机器和他登录请求的机器不一致，或者登录请求的机器宕机了，session 不就失效了吗？这个问题现在有几种解决方式。
但通常还是采用第一种方式，因为第二种相当于阉割了负载均衡，且仍没有解决「用户请求的机器宕机」的问题。「nodejs 下的 session 处理」前面的图很清楚了，服务端要实现对 cookie 和 session 的存取，实现起来要做的事还是很多的。在npm中，已经有封装好的中间件，比如 express-session - npm，用法就不贴了。这是它种的 cookie：
express-session - npm 主要实现了：
session 的维护给服务端造成很大困扰，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套 Redis 集群。有没有更好的办法？
回过头来想想，一个登录场景，也不必往 session 存太多东西，那为什么不直接打包到 cookie 中呢？这样服务端不用存了，每次只要核验 cookie 带的「证件」有效性就可以了，也可以携带一些轻量的信息。这种方式通常被叫做 token。
token 的流程是这样的：
「客户端 token 的存储方式」 在前面 cookie 说过，cookie 并不是客户端存储凭证的唯一方式。token 因为它的「无状态性」，有效期、使用限制都包在 token 内容里，对 cookie 的管理能力依赖较小，客户端存起来就显得更自由。但 web 应用的主流方式仍是放在 cookie 里，毕竟少操心。 「token 的过期」那我们如何控制 token 的有效期呢？很简单，把「过期时间」和数据一起塞进去，验证时判断就好。
编码的方式丰俭由人。「base64」比如 node 端的 cookie-session - npm 库
默认配置下，当我给他一个 userid，他会存成这样：
这里的 eyJ1c2VyaWQiOiJhIn0=，就是 {"userid":"abb”} 的 base64 而已。 「防篡改」
是的。所以看情况，如果 token 涉及到敏感权限，就要想办法避免 token 被篡改。解决方案就是给 token 加签名，来识别 token 是否被篡改过。例如在 cookie-session - npm 库中，增加两项配置：
这样会多种一个 sig cookie，里面的值就是 {"userid":"abb”} 和 iAmSecret通过加密算法计算出来的，常见的比如HMACSHA256 类 (SystemSecurityCryptography) | Microsoft Docs。
好了，现在 cdd 虽然能伪造出eyJ1c2VyaWQiOiJhIn0=，但伪造不出 sig 的内容，因为他不知道 secret。「JWT」但上面的做法额外增加了 cookie 数量，数据本身也没有规范的格式，所以 JSON Web Token Introduction - jwtio 横空出世了。
它是一种成熟的 token 字符串生成方案，包含了我们前面提到的数据、签名。不如直接看一下一个 JWT token 长什么样：
这串东西是怎么生成的呢？看图：
类型、加密算法的选项，以及 JWT 标准数据字段，可以参考 RFC 7519 - JSON Web Token (JWT)node 上同样有相关的库实现：express-jwt - npm koa-jwt - npm
token，作为权限守护者，最重要的就是「安全」。业务接口用来鉴权的 token，我们称之为 access token。越是权限敏感的业务，我们越希望 access token 有效期足够短，以避免被盗用。但过短的有效期会造成 access token 经常过期，过期后怎么办呢？一种办法是，让用户重新登录获取新 token，显然不够友好，要知道有的 access token 过期时间可能只有几分钟。另外一种办法是，再来一个 token，一个专门生成 access token 的 token，我们称为 refresh token。
有了 refresh token 后，几种情况的请求流程变成这样：
如果 refresh token 也过期了，就只能重新登录了。
session 和 token 都是边界很模糊的概念，就像前面说的，refresh token 也可能以 session 的形式组织维护。狭义上，我们通常认为 session 是「种在 cookie 上、数据存在服务端」的认证方案，token 是「客户端存哪都行、数据存在 token 里」的认证方案。对 session 和 token 的对比本质上是「客户端存 cookie / 存别地儿」、「服务端存数据 / 不存数据」的对比。「客户端存 cookie / 存别地儿」存 cookie 固然方便不操心，但问题也很明显：
存别的地方，可以解决没有 cookie 的场景；通过参数等方式手动带，可以避免 CSRF 攻击。 「服务端存数据 / 不存数据」
前面我们已经知道了，在同域下的客户端/服务端认证系统中，通过客户端携带凭证，维持一段时间内的登录状态。但当我们业务线越来越多，就会有更多业务系统分散到不同域名下，就需要「一次登录，全线通用」的能力，叫做「单点登录」。
简单的，如果业务系统都在同一主域名下，比如wenkubaiducom tiebabaiducom，就好办了。可以直接把 cookie domain 设置为主域名 baiducom，百度也就是这么干的。
比如滴滴这么潮的公司，同时拥有didichuxingcom xiaojukejicom didiglobalcom等域名，种 cookie 是完全绕不开的。这要能实现「一次登录，全线通用」，才是真正的单点登录。这种场景下，我们需要独立的认证服务，通常被称为 SSO。 「一次「从 A 系统引发登录，到 B 系统不用登录」的完整流程」
「完整版本：考虑浏览器的场景」上面的过程看起来没问题，实际上很多 APP 等端上这样就够了。但在浏览器下不见得好用。看这里：
对浏览器来说，SSO 域下返回的数据要怎么存，才能在访问 A 的时候带上？浏览器对跨域有严格限制，cookie、localStorage 等方式都是有域限制的。这就需要也只能由 A 提供 A 域下存储凭证的能力。一般我们是这么做的：
图中我们通过颜色把浏览器当前所处的域名标记出来。注意图中灰底文字说明部分的变化。
谢谢大家哦
0条评论