登录之后，在其他页面怎么判断是否已经登录？

登陆验证是网站的基本需求之一，通过登陆为用户展示特定的信息与页面，登陆验证可以保护用户的个人信息，避免遭到他人的篡改与破坏。 通过在登陆时记录一个数据，然后在需要进行登陆验证的页面比较此数据，若数据与登陆时记录的数据相符，则通过验证，否则不通过验证。这要求此数据是稳定的，不随url的变化而改变。即本地存储的方法。1.Cookies：浏览器均支持，容量为4KB，默认生命周期为浏览器窗口，默认作用域为本目录 2.Session：服务器端的存储。 3.LocalStorage：HTML5，容量为5M,生命周期是永久，作用域为文档源级别，即同协议、同主机名、相端口。 4.SesstionStorage：HTML5，容量为5M,生命周期为当前标签页,作用域是标签页级别//设置cookie document.cookie= 'name=xiaoyu' //编辑cookie document.cookie= 'name=desu' //获取cookie某一项的值 functiongetCookie(name) { var arr, reg = new RegExp("(^| )" + name +"=([^]*)(|$)") if (arr = document.cookie.match(reg)) { console.log(document.cookie.match(reg)) return encodedURI(arr[2]) } else { return null } }开启了Session支持的服务器在客户端开始会话的时候，生成一个SessionID，并且在响应（Response）头（Headers）中的Set-Cookie字段设置一个Cookie，Cookie的内容就是SessionID和Cookie的路径（path），在后继的会话中，客户端浏览器会自动附上Set-Cookie中的SessionID以向服务器表明身份，服务器根据SessionID在自己的存储中查找相关用户信息，并完成验证过程。 那么用户登陆的过程也就是用户对服务器提交用户名、密码等信息，获取SessionID的过程。 两者用法相同： //保存数据到sessionStorage sessionStorage.setItem('key', 'value') //从sessionStorage获取数据 sessionStorage.getItem('key') sessionStorage.key //从sessionStorage删除保存的数据 sessionStorage.removeItem('key') //从sessionStorage删除所有保存的数据 sessionStorage.clear()1.cookie始终在服务器和浏览器之间来回传送，明文传递，不够安全，且占用了带宽。数据大小受限，只有4kb，对cookie的操作也比较繁琐。 2.session保存在服务器端，数据安全。对数据的操作需要后端协助。 3.localStorage,永久存储且可存入大量数据，但如果数据过多，打开浏览器时会比较卡。4.sessionStorage，生命周期和作用域都比较窄，这是优点也是缺点。1.参考一： Javascript本地存储小结2.参考二： Session和Cookie的区别及Session的生命周期 根据特性使用，若需要永久存储，则选择localStorage，若需要关闭网页就销毁数据，则选择sessionStorage 不是，虽然cookie有着诸多缺点，但cookie也有许多不可替代的特性，比如可以灵活的设置过期时间，也可以设置作用域。能在服务器和客户端进行数据交互。 Webstorage不会传递到服务器端，且webStorage就是为了解决cookie频繁在服务器和客户端交互的弊端而设，webstorage就是为了在客户端存储数据而生，不应舍本逐末。

首先,只要不在session中存放大量信息,和设置session过期时间短点,只要合理的使用,不会很耗服务器资源的.

其次要想使用其他方法,cookies也是可以的.但缺陷是,如果用户禁用浏览器cookies,就不能使用此种方案了.

第三种方法,使用数据库,可以把用户登录信息保存在数据库,具体方案就是用户登录,保存信息到数据库,但需要判断用户登录超时或者用户已经退出访问,然后在数据库删除此信息.

粗略地分析， 登录机制主要分为登录验证、登录保持、登出三个部分。登录验证是指客户端提供用户名和密码，向服务器提出登录请求，服务器判断客户端是否可以登录并向客户端确认。 登录认保持是指客户端登录后， 服务器能够分辨出已登录的客户端，并为其持续提供登录权限的服务器。登出是指客户端主动退出登录状态。容易想到的方案是，客户端登录成功后， 服务器为其分配sessionId, 客户端随后每次请求资源时都带上sessionId。

上述简易的登录验证策略存在明显的安全漏洞,需要优化。

客户端第一次发出登录请求时， 用户密码以明文的方式传输， 一旦被截获， 后果严重。因此密码需要加密，例如可采用RSA非对称加密。具体流程如下：

再仔细核对上述登录流程， 我们发现服务器判断用户是否登录， 完全依赖于sessionId, 一旦其被截获， 黑客就能够模拟出用户的请求。于是我们需要引入token的概念： 用户登录成功后， 服务器不但为其分配了sessionId, 还分配了token， token是维持登录状态的关键秘密数据。在服务器向客户端发送的token数据，也需要加密。于是一次登录的细节再次扩展。

在最原始的方案中， 登录保持仅仅靠服务器生成的sessionId: 客户端的请求中带上sessionId, 如果服务器的redis中存在这个id，就认为请求来自相应的登录客户端。 但是只要sessionId被截获， 请求就可以为伪造， 存在安全隐患。

引入token后，上述问题便可得到解决。 服务器将token和其它的一些变量， 利用散列加密算法得到签名后，连同sessionId一并发送给服务器； 服务器取出保存于服务器端的token,利用相同的法则生成校验签名， 如果客户端签名与服务器的校验签名一致， 就认为请求来自登录的客户端。

1.3 TOKEN失效

用户登录出系统

失效原理：

在服务器端的redis中删除相应key为session的键值对。

App因为要实现自动登陆功能，所以必然要保存一些凭据，所以比较复杂。

App登陆要实现的功能：

这里判断时间，主要是防止攻击者截取到加密串后，可以长久地利用这个加密串来登陆。

不用AES加密，用RSA公钥加密也是可以的。AES速度比RSA要快，RSA只能存储有限的数据。

---