session和cookie的详解 - CODE男孩的博客 - CSDN博客
session和cookie的详解
session和cookie是浏览中较为常见的两个概念，也是比较难以辨析的两个概念，但它们在点击流及基于用户浏览行为的分析中却相当关键。基于网上一些文章和资料的参阅，及作者个人的应用体会，对这两个概念做一个简单的阐述和辨析，希望能与大家共同探讨下。
　　session和cookie的最大区别在于session是保存在服务端的内存里面，而cookie保存于浏览器或客户端文件里面；session是基于访问的进程，记录了一个访问的开始到结束，当浏览器或进程关闭之后，session也就“消失”了，而cookie更多地被用于标识用户，它可以是长久的，用于用户跟踪和识别唯一用户（Unique Visitor）。
关于session
　　session被用于表示一个持续的连接状态，在访问中一般指代客户端浏览器的进程从开启到结束的过程。session其实就是分析的访问（visits）度量，表示一个访问的过程。
　　session的常见实现形式是会话cookie（session cookie），即未设置过期时间的cookie，这个cookie的默认生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。实现机制是当用户发起一个请求的时候，会检查该请求中是否包含sessionid，如果未包含，则系统会创造一个名为JSESSIONID的输出
cookie返回给浏览器(只放入内存，并不存在硬盘中)，并将其以HashTable的形式写到的内存里面；当已经包含sessionid是，服务端会检查找到与该session相匹配的信息，如果存在则直接使用该sessionid，若不存在则重新生成新的
session。这里需要注意的是session始终是有服务端创建的，并非浏览器自己生成的。
　　但是浏览器的cookie被禁止后session就需要用get方法的URL重写的机制或使用POST方法提交隐藏表单的形式来实现。
　　这里有一个很关键性的注意点，即session失效时间的设置，这里要分两方面来看：浏览器端和服务端。对于浏览器端而言，session与访问进程直接相关，当浏览器被关闭时，session也随之消失；而端的session失效时间一般是人为设置的，目的是能定期地释放内存空间，减小压力，一般的设置为当会话处于非活动状态达20或30分钟时清除该
session，所以浏览器端和服务端的session并非同时消失的，session的中断也并不一定意味着用户一定离开了该。目前Google
Analytics和Omniture都定义当间隔30分钟没有动作时，算作一次访问结束，所以上图中session的最后一步不只是离开，也有可能是静止、休眠或者发呆的状态。
　　还有一点需要注意，就是现在的浏览器好像趋向于多进程的session共享，即通过多个标签或页面打开多个进程访问同一时共享一个 session
cookie，只有当浏览器被关闭时才会被清除，也就是你有可能在标签中关闭了该，但只要浏览器未被关闭并且在端的session未失效前重新开启该，那么就还是使用原session进行浏览；而某些浏览器在打开多页面时也可能建立独立的session，IE8、Chrome默认都是共享
session的，在IE8中可以通过菜单栏中的文件-&新建会话来建立独立session的浏览页面。
关于cookie&
　　cookie 是一小段文本信息，伴随着用户请求和页面在Web和浏览器之间传递。用户每次访问站点时，Web应用程序都可以读取cookie包含的信息。
　　session的实现机制里面已经介绍了常见的方法是使用会话cookie（session cookie）的方式，而平常所说的cookie主要指的是另一类cookie——持久cookie（persistent cookies）。持久cookie是指存放于客户端硬盘中的 cookie信息（设置了一定的有效期限），当用户访问某时，浏览器就会在本地硬盘上查找与该相关联的cookie。如果该cookie
存在，浏览器就将它与页面请求一起通过HTTP报头信息发送到您的站点，然后在系统会比对cookie中各属性和值是否与存放在端的信息一致，并根据比对结果确定用户为“初访者”或者“老客户”。
　　持久cookie一般会保存用户的用户ID，该信息在用户注册或第一次登录的时候由生成包含域名及相关信息的cookie发送并存放到客户端的硬盘文件上，并设置cookie的过期时间，以便于实现用户的自动登录和内容自定义。
　　Apache自带的mod_usertrack模块可以在用户首次来到当前的时候给用户种下一个唯一的cookie（较长时间过期），这个 cookie是用户首次来当前的IP地址加上一个随机字符串组成的。同时在自定义WEB日志中在最后增加%{cookie}n字段可以实现
cookie在apache日志中的输出，用于数据统计与用户跟踪。
当你在浏览网站的时候，WEB 服务器会先送一小小资料放在你的计算机上，Cookie 会帮你在网站上所打的文字或是一些选择，
都纪录下来。当下次你再光临同一个网站，WEB 服务器会先看看有没有它上次留下的 Cookie 资料，有的话，就会依据 Cookie
里的内容来判断使用者，送出特定的网页内容给你。 Cookie 的使用很普遍，许多有提供个人化服务的网站，都是利用 Cookie
来辨认使用者，以方便送出使用者量身定做的内容，像是 Web 接口的免费 email 网站，都要用到 Cookie。
具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。
同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制
来达到保存标识的目的，但实际上它还有其他选择。
cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示
浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie的使用
是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围
大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。
cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这
个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。
会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie
保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏
览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式
session机制。session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。
&&&&&&&&&&当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识
（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来
使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相
关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应
中返回给客户端保存。保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给
服务器。一般这个cookie的名字都是类似于SEEESIONID。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时
仍然能够把session id传递回服务器。
经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器
会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如：&
&form name=&testform& action=&/xxx&&&
&input type=&hidden& name=&jsessionid& value=&ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-&&&
&input type=&text&&&
实际上这种技术可以简单的用对action应用URL重写来代替。
Session的生命周期：
我们已经知道，Session是在用户第一次访问网站的时候创建的，那么Session是什么时候销毁的呢？其实，Session使用一种平滑超时的技术来控制何时销毁Session。默认情况下，Session的超时时间（Timeout）是20分钟，即用户保持连续20分钟不访问网站，则Session被收回。如果在这20分钟内用户又访问了一次页面，那么20分钟就重新计时了。也就是说，这个超时是连续不访问的超时时间，而不是第一次访问后20分钟必过时。当然，你可以通过修改Web.config文件的配置项来调整这个超时时间，如下面的代码所示：
除了以上在web.config中设置session的有效时间之外，还可以直接程序中设置，如下面代码如所示：
以上设置session的有效时间为30分钟，一旦时间到期，则程序会自动重新分配一个新的sessionID。 不过，你可别太相信Session的Timeout属性，如果你把它设置为24小时，则很难相信24小时之后用户的Session还在。Session是否存在，不仅仅依赖于Timeout属性，以下的情况都可能引起 Session丢失：
1）bin目录中的文件被改写。asp.net有一种机制，为了保证dll重新编译之后，系统正常运行，它会重新启动一次网站进程，这时就会导致Session丢失。
2）SessionID丢失或者无效。如果你在URL中存储SessionID，但是使用了绝对地址重定向网站导致URL中的SessionID丢失，那么原来的Session将失效。如果你在Cookie中存储SessionID，那么客户端禁用Cookie或者Cookie达到了IE中Cookie数量的限制（每个域20个），那么Session将无效。
3）如果使用InProc的Session，那么IIS重启将会丢失Session。同理，如果使用StateServer的 Session，服务器重新启动Session也会丢失。
以上是可能会引起session丢失的几个原因，有时候，我还需要立刻让Session失效。比如用户退出系统后，Session中保存的所有数据需要全部失效。处理方法如下面的代码所示：
[csharp]&&
cookie 和session 的区别：
1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
&& 考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
&& 考虑到减轻服务器性能方面，应当使用COOKIE。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
5、所以个人建议：
&& 将登陆信息等重要信息存放为SESSION
&& 其他信息如果需要保留，可以放在COOKIE中
我的热门文章关于 Token，你应该知道的十件事 - 为程序员服务
关于 Token，你应该知道的十件事
29894 阅读
原文是一篇很好的讲述 Token 在 Web 应用中使用的，而这是我和
合作翻译的译文。
1. Token 应该被保存起来（放到 local / session stograge 或者 cookies）
在单页应用程序中，有些用户刷新浏览器后会带来一些跟 token 相关的问题。而解决方法很简单：你应该把 token 保存到起来：。而浏览器不支持 session storage 时都应该转存到 cookies 里。
如果你想“我把 token 保存到 cookie ，不就跟以前没有任何分别？”。可是在这种情况下你只是把 cookie 当作一个储存机制，而不是一种。（比如说，这个 cookie 不会被 Web 框架用于用户验证，所以没有 XSRF 攻击的危险）。
2. Tokens 除了像 cookie 一样有有效期，而且你可以有更多的操作方法
Tokens 应该有一个有效期（在
中是作为 exp 属性），否则其他人只要登录过一次就可以永远地通过 API 的验证。Cookies 基于同样的理由也有一个有效期。
在 Cookies 的使用中，有不同的选项可以控制 cookie 的生命周期：
. cookies 可以在浏览器关闭后删除（session cookies）；
. 另外你可以实现服务器端的检查（通常由你使用的 Web 框架完成），还有也可以实现绝对有效期或弹性有效期（sliding window expiration）；
. Cookies 可以带有有效期地保存起来（浏览器关闭后也不删除）。
而在 tokens 的使用中，一旦 token 过期，只需要重新获取一个。你可以使用一个接口去刷新 token：
. 让旧的 token 失效；
. 检查这个用户是不是还存在，权限是否被取消或者任何对你的程序来说是有必要的；
. 得到一个更新了有效期的 token。
你甚至可以把 token 原来的发布时间也保存起来，并且强制在两星期后重新登录什么的。
app.post('/refresh_token', function (req, res) {
// verify the existing token
var profile = jwt.verify(req.body.token, secret);
// if more than 14 days old, force login
if (profile.original_iat - new Date() & 14) { // iat == issued at
return res.send(401); // re-logging
// check if the user still exists or if authorization hasn't been revoked
if (!valid) return res.send(401); // re-logging
// issue a new token
var refreshed_token = jwt.sign(profile, secret, { expiresInMinutes: 60*5 });
res.json({ token: refreshed_token });
如果你需要撤回 tokens（当 token 的生存期比较长的时候这很有必要）那么你需要一个 token 的生成管理器去作检查。
3. Local / session storage 不会跨域工作，请使用一个标记 cookie
如果你设置一个 cookie 的域名为 . 它将可以被 < 和
获取，这样用户登录并且转到
后也能很容易地从主域名找回这个 cookie（假如你的是电商网站）。
而另一方面，保存在 local / session storage 的 tokens，就不能从不同的域名中读取（甚至是子域名也不行）。那你能怎么做？
一个可能的选择是，当用户通过
上面的验证时你生成一个 token 并且作为一个 cookie 保存到 .
$.post('/authenticate, function() {
// store token on local/session storage or cookie
// create a cookie signaling that user is logged in
$.cookie('loggedin', profile.name, '.');
然后，在 < 中你可以检查这个 cookie 是不是已经存在了，并且如果存在的话就转到 去。从这以后，这个 token 将会对程序的子域名以及之后通常的流程都有效（直到这个 token 超过有效期）。
不过这将会导致 cookie 存在但 token 被删除了或其他意外情况的发生。在这种情况下，用户将不得不重新登录。但重要的是，像我们之前说的，我们不会这个用 cookie 作为验证方法，只是作为一个存储机制去支持存储信息在不同的域名中。
4. 每个 CORS（跨域资源共享）请求都会带上预请求（Preflight request）
有些人指出 Authorization header 不是一个，因此对于一个特定的 URLs 的所有请求都会带上一个预请求。
OPTIONS /bar
Authorization: Bearer ....
OPTIONS /bar2
Authorization: Bearer ....
Authorization: Bearer ....
但这只会发生在你发送 Content-Type: application/json 时。不过这说明已经出现在绝大多数的程序中了。
一个小小的警告，the OPTIONS 请求不会带有 Authorization header 自身，所以你的网络框架应该支持区别对待 OPTISON 和后来的请求。（微软的 IIS 因为某些原因好像会有问题）。
5. 当你需要流传送某些东西，请用 token 去获取一个已签名的请求。
当使用 cookies 时，你可以很容易开始一个文件的下载或流传送内容。然而，在 tokens 的使用中，请求是通过 XHR 完成的，你不能依赖于它。而解决方法应该是像 AWS 那样通过生成一个签名了的请求，例如，Hawk Bewits 是一个很好的框架去启用它：
POST /download-file/123
Authorization: Bearer...
ticket=lahdoiasdhoiwdowijaksjdoaisdjoasidja
这个 ticket 是无状态并且是基于 URL 的：host + path + query + headers + timestamp + HMAC，并且有一个有效期。所以它可以用于像只能在5分钟内去下载一个文件。
你然后可以转到 /download-file/123? ticket=lahdoiasdhoiwdowijaksjdoaisdjoasidja 中去。服务器就会检查这个 ticket 是不是有效然后像正常一样开始下一步的服务。
要更容易防范
XSS 攻击的原理是，攻击者插入一段可执行的 JavaScripts 脚本，该脚本会读出用户浏览器的 cookies 并将它传输给攻击者，攻击者得到用户的 Cookies 后，即可冒充用户。但是要防范 XSS 也很简单，在写入 cookies 时，将 HttpOnly 设置为 true，客户端 JavaScripts 就无法读取该 cookies 的值，就可以有效防范 XSS 攻击。因为 Tokens 也是储存在本地的 session storage 或者是客户端的 cookies 中，也是会受到 XSS 攻击。所以在使用 tokens 的时候，必须要考虑过期机制，不然攻击者就可以永久持有受害用户帐号。
相比 XSS，XSRF 的危害性更大，因为大多数 Web 框架都已经内置了 XSS 防范机制（例如在 Ruby on Rails 中，用户的输入在输出的时候都会做转义操作，攻击者插入的脚本就无法执行），对于大部分开发者而言，甚至连 XSRF 都不知道是什么玩意，更别提防范了。XSRF 目前并不是每个 Web 框架都有防范机制，因此开发者更应该留意 XSRF 。
7. 注意 token 的大小
Token 机制在每次请求 API 的时候，都需要带上一个 Authorization 的 Http Header 。
Authorization: Bearer ...2kb token...
connect.sid: ...20 bytes cookie...
Token 的大小其实由你储存在 token 中的信息量所决定，例如可能有 nickname，openid 等开发者另外加上的信息。
但是 session cookies 机制只需要一个字串作为用户标识即可（例如 PHP 的 PHPSESSIONID），其中关于用户的信息都会直接储存到服务端的数据库中，当用户请求时才从数据库中捞出来用。
当然 Token 机制也可以仿照 session cookies 机制这么做了，也是个有效控制 token 大小的方法。
Token 中只保留关键的几条身份标识信息，其余都放到数据库里面了，权限控制的时候再捞出。这样做的好处是，开发者可以完全掌控 token，因为关键信息都已经是你代码和数据库中的一部分了，想怎么弄都可以了。
举个例子：
Authorization: Bearer ……500 bytes token….
Then on the server:
app.use('/api',
// 首先检查 token；
expressJwt({secret: secret}),
// 然后再从数据库中捞出用户信息。
function(req, res, next) {
req.user.extra_data = get_from_db();
另外值得一提的是，你也可以把东西都丢 Cookies 里面（而不是只丢个身份标识字串）。只要确保资料经过了严格的加密，攻击者无法利用，现在有些 Web 框架已经有类似机制，例如 Nodejs 的这个插件 。
8. 有需要的话，要加密并且签名 token
虽然 TLS/SSL 机制可以隔绝大多数中间人攻击，但是如果 token 中带有了用户的敏感信息，开发者也应该要加密这些信息。
使用 JWT（文中第 9 点） 可以加密 token，但是由于目前大多数 Web 框架还未支持 JWT，所以可以使用 AES-CBC 算法加密 token。
app.post('/authenticate', function (req, res) {
// 校验用户；
// 加密 token；
var encrypted = { token: encryptAesSha256('shhhh', JSON.stringify(profile)) };
// 给加密后的 token 签名；
var token = jwt.sign(encrypted, secret, { expiresInMinutes: 60*5 });
res.json({ token: token });
function encryptAesSha256 (password, textToEncrypt) {
var cipher = crypto.createCipher('aes-256-cbc', password);
var crypted = cipher.update(textToEncrypt, 'utf8', 'hex');
crypted += cipher.final('hex');
// 上面就是 encrypt-then-MAC （加密后签名）做法。
当然你也可以用文中的第 7 点，直接将敏感信息丢数据库中。
9. 将 JSON Web Tokens 应用到 OAuth 2
OAuth 2 是一个解决身份验证的授权协议，并且广泛地使用了 token 。
用户通过 OAuth 2 协议授权第三方应用权限，然后服务器返回一个 access_token 给第三方应用，通常也带有 scope 参数，第三方应用通过带上 access_token 请求服务器，可以在授权范围（scope）内调用 API。
一般来说，类似这种 token 是不透明的，就是核心数据都储存以 hash-table 结果储存在服务器中，客户端只持有一个令牌（access_token），任何人都可以用这个令牌在授权范围（scope）内调用服务器端的 API。
Signed tokens（例如 )）和这种形式的 token 最主要的区别是，JWT 是无状态的，它不储存在服务端 hash-table 中，服务端中不保留 JWT 请求的相关信息，JWT 会把授权信息和 API 调用返回都丢一起返回给客户端。
JWT 通常以 Base64 + AES 方式编码传输。OAuth 2 协议也支持 JWT，因为 OAuth 2 并未限制 access_token 数据格式，你可以将 JWT 应用在 OAuth 2 上。
10. Tokens 不是万能的解决方法，得根据你的需求自行采用
这些年来，我们帮助过不少大公司实现了他们的以 Token 为基础的验证授权架构。曾经有一家 10k + 员工，有着大量数据的公司，他们想实现一个中央权限管理系统，其中有一个需要是某个员工只能读取某个国家某个医院某个床位的id和name字段数据，想想这样的细粒度的权限管理是多么难实现，无论是技术上还是行政上。
当然采用 tokens 与否，得看大家的具体需求，但是，要忠告大家的是，不要什么内容都写到 tokens 了，加之前想想有没有这个必要。
原文地址：, 感谢原作者分享。
您可能感兴趣的代码浅谈Cookie的生命周期问题
投稿：jingxian
字体：[ ] 类型：转载 时间：
下面小编就为大家带来一篇浅谈Cookie的生命周期问题。小编觉得挺不错的，现在就分享给大家，也给大家做个参考。一起跟随小编过来看看吧
设置Cookie对象的有效时间， setMaxAge()方法便可以设置Cookie对象的有效时间，
例如：Cookie c = new Cookie("username","john");
c.setMaxAge(60);//60秒的意思
c.setMaxAge(60*60);//一小时
c.setMaxAge(365*24*60*60);//一年
如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。
这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。
cookie.setmaxage设置为0时，会马上在浏览器上删除指定的cookie
cookie.setmaxage设置为-1时，代表关闭当前浏览器即失效。
以上这篇浅谈Cookie的生命周期问题就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持脚本之家。
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具session 和 cookie区别
编辑：www.fx114.net
本篇文章主要介绍了"session 和 cookie区别 "，主要涉及到session 和 cookie区别 方面的内容，对于session 和 cookie区别 感兴趣的同学可以参考一下。
1、存在位置cookie是储存在客服端，session是存在服务器端的文件系统/数据库/memcache& 2、安全性 session是储存在服务器端，安全性高一些，
3、网络传输量 cookie通过网络在客户端与服务器端传输，而session保存在服务器端，不需要传输。 4、生命周期（20分钟为例） (1)cookie的生命周期是累计的，从创建时就开始记时，20分钟后cookie生命周期结束，cookie就无效 (2)session的生命周期是间隔的，从创建时开始计时，如果在20分钟没有访问过session，那么session信息就无效，如果在20分钟内，比如19分钟的时候访问过session，那么，他的生命周期将重新开始计算。
一、不得利用本站危害国家安全、泄露国家秘密，不得侵犯国家社会集体的和公民的合法权益，不得利用本站制作、复制和传播不法有害信息！
二、互相尊重，对自己的言论和行为负责。
本文标题：
本页链接：cookie、session及实现记住密码，自动登录 - CSDN博客
cookie、session及实现记住密码，自动登录
本文已收录于以下专栏：
相关文章推荐
标签：cookie session
在登录帐号、密码框下，有三种帐号登录模式可供选择，用户可根据自己的具体情况选择其中一种适合自己的模式。
1、网吧模式：勾选网吧模式后，登录的帐号会在...
来源url:http://heyohsmm./9615
在登录帐号、密码框下，有三种帐号登录模式可供选择，用户可根据自己的具体情况选择其中一...
cookie实现自动登陆原理
protected void Page_Load(object sender, EventArgs e)
if (!IsPostBack)
每次在进入登录页面的时候都要进行用户名和密码的输入，用户的体验不好。
使用cookie来实现记住密码的功能。我实现的是逻辑比较简单的记住密码操作；并没有涉及安全性比较高的业务；比如说与支付相关的密码...
近来做记住密码时，用js的实现方式做了一下。
login.jsp页面代码
欢迎转载，但请保留文章原始出处→_→
生命壹号：/smyhvae/
文章来源：/smyhvae/p/409...
网上借鉴了一些朋友的经验，做了一个小例子，js操作cookie，实现登录密码保存。cookie的存放方式是以键值对的方式保存的。
通常cookie和session，是web开发中用于存储信息的对象，s...
cookie是什么 cookie怎么简单记住客户端账户,免登陆
cookie是什么？
甜甜圈，其实cookie简单理解就是客户端用来放一些键值对的客户端对象，把它简单理解成一个放在客...
他的最新文章
讲师：王禹华
讲师：宋宝华
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)}