大家都知道，OSP是不支持session的，换句话说，登录有效期是永久的。一般网站，如果你不操作一段时间以后，必须重新登录。osp不是这样的，你一旦登录后，即便服务器重启了，你依然能访问服务器并不需要重新登录，服务器依然知道访问的是用户是谁；你打开浏览器登录了osp，然后再打开一个新页面，它还让你重新登录。我们分别分析下一般网站的和OSP的区别。
1、一般网站为何超时后必须重新登录
为何要求超时，这纯粹是处于安全考虑。它是怎么做到的呢。session！session翻译成会话，代表你从登陆到退出这段时间。技术上，session保存在服务端，一个登陆对应一个。如果有你的session，表示你的登录时有效的，否则你就不能访问系统。大家都知道http协议是无状态的，第一次访问和第二次访问本质上是无关的。那么服务器怎么知道来自客户端的一次访问对应服务器内的哪个session呢？
cookie大家都知道吧，是网站存储在浏览器本地的一些数据。游览器有个很重要的特性，每次访问服务器的时候，它都会把属于这个服务器域名的所有cookie都带上，发送给服务器。这是http协议的一部分。服务器能得到每个cookie的值。使用cookie识别“你”是有可能的：
（1）你访问京东网jd.com，登陆，登陆成功后，服务器随机生成一小块数据（确保每次生成的都不重复，比如guid串），返回给浏览器，浏览器保存下来，给这块数据起个名字叫“sessionID"。同时呢服务器上也把这个sessionID记录下来，并与登陆账号建立关系。
（2）随后，你再次访问京东，比如点击某个商品，浏览器会把这块命名为sessionID的数据发送给京东网站，京东网站根据名字拿到这个数据，到session列表里一查，查到这个数据了，同时根据这个数据找打关联的账号，这就知道，这次访问的是 “你”。这就是session 和 cookie的关系和用处。
那超时是怎么实现的呢，简单，服务器在记录sessionID的时候， 同时记录下来你最后一次访问服务器的时间，如果你再次访问，和上次访问的时间间隔超过了设定的时间，比如30分钟，服务器就认为，你太久没来了，不认你这个sessionID了。你的登录信息失效了！
如果浏览器禁用cookie怎么办（出于保护隐私目的，有的人会禁用cookie）。那网页就把表示session的cookie记录在内存中，每次访问网站是，就用get方式传给服务器（在url后加上 ？sessionID=xxxxx）（js脚本可以判断浏览器是否禁止了cookie）。
2、OSP
回过来我们在说说ops。前面说osp不支持session。有三个意思：
（1）osp服务器没有记录你的登陆信息
（2）所以你的登陆永远也不会超时
回过来我们在说说ops。前面说osp不支持session。有三个意思：
（1）osp服务器没有记录你的登陆信息
（2）所以你的登陆永远也不会超时
那问题来了，既然服务器没有记录你的登录信息，那么在osp客户端访问服务器时，服务器怎么知道来客是谁呢？这个你肯定知道：osp登录后，把登录信息（比如账号）保存在客户端内存（网页）了。他每次访问服务器是，总是传给服务器（通过PO），说我胡汉三又来了。这是osp和一般web应用区别之一：一般wen应用是将登录信息保存在服务器端（session），客户端和服务器端值传送sessionid，通过sessionID在服务端查找登录信息，osp呢，把登陆信息保存在客户端，每次都要传登录信息给服务端。
3、osp的问题
（1）osp没有统一的安全校验机制（当然这个问题和它没有session概念没有关系），也就是说，服务器端没有做访问拦截（除了第一次登录时验证过一次），只要你访问服务器，他就接受你的请求，调用对应的后台程序。除非你后台程序自己做检查。所以这个登录基本上是没有啥意思，你完全可以写程序绕过osp的登陆页面。，直接访问数据。
这种做法，显然通过不过安全程序的检查。一扫描就把漏洞扫描出来了。
（2）无法禁止重复登录。因为他没记录你的登录信息吗，当然他也没有程序做这个检查。
（1）osp没有统一的安全校验机制（当然这个问题和它没有session概念没有关系），也就是说，服务器端没有做访问拦截（除了第一次登录时验证过一次），只要你访问服务器，他就接受你的请求，调用对应的后台程序。除非你后台程序自己做检查。所以这个登录基本上是没有啥意思，你完全可以写程序绕过osp的登陆页面。，直接访问数据。
这种做法，显然通过不过安全程序的检查。一扫描就把漏洞扫描出来了。
（2）无法禁止重复登录。因为他没记录你的登录信息吗，当然他也没有程序做这个检查。
4，如何解决和实现
以上两个问题一块考虑。
我们参考一般web应用的做法，实现session，在服务器端记录你的登录信息，而不是在客户端。以下是实现：
- 服务器：
登录验证成功后，（1）生成唯一的一段数据，通过ro返回给客户端，命名为sessionID。（2）检查这个用户是否有其他有效的session，如果有并且不允许多点登录，就把其他的session删除掉（其他登录再次访问时，就失效了，被踢出去了。这个解决了osp的第二个问题：不能禁止重复登录）。（3）在内存或者数据库，把这个sessionID记录下来，并记录和这个session关联的账号，该session最后一次访问的时间（客户端活跃时间）。
- 客户端：
登录成功后，（1）将收到的sessionID保存起来（保存在cookie或者内存，OSP是保存在内存，一般web应用是保存在cookie）。（2）（如果没有保存在cookie），每次请求，在po里吧sessionID传给服务器；如果保存在cookie，就不用管了，浏览器会自动给你带过去。
- 服务器：收到请求后，首先通过拦截器，检查登录是否有效：拿到客户端传过来的sessionID（通过cookie或者PO），在服务器上查找这个session，如果找不到，或者虽然找到但是失效了（是否超时），就定向到登录页面；否则执行请求的操作。
以上两个问题一块考虑。
我们参考一般web应用的做法，实现session，在服务器端记录你的登录信息，而不是在客户端。以下是实现：
- 服务器：
登录验证成功后，（1）生成唯一的一段数据，通过ro返回给客户端，命名为sessionID。（2）检查这个用户是否有其他有效的session，如果有并且不允许多点登录，就把其他的session删除掉（其他登录再次访问时，就失效了，被踢出去了。这个解决了osp的第二个问题：不能禁止重复登录）。（3）在内存或者数据库，把这个sessionID记录下来，并记录和这个session关联的账号，该session最后一次访问的时间（客户端活跃时间）。
- 客户端：
登录成功后，（1）将收到的sessionID保存起来（保存在cookie或者内存，OSP是保存在内存，一般web应用是保存在cookie）。（2）（如果没有保存在cookie），每次请求，在po里吧sessionID传给服务器；如果保存在cookie，就不用管了，浏览器会自动给你带过去。
- 服务器：收到请求后，首先通过拦截器，检查登录是否有效：拿到客户端传过来的sessionID（通过cookie或者PO），在服务器上查找这个session，如果找不到，或者虽然找到但是失效了（是否超时），就定向到登录页面；否则执行请求的操作。
5、session 怎么保存的问题
（1）保存在服务器内存
优点：速度快，
缺点：（1）如果使用的负载均衡，session在多个服务器之间不能共享，需要额外的同步机制；（2）一旦服务器重启，session就丢失了
（2）保存在数据库
优点：支持session共享和负载均衡；session能持久化存储。
缺点：性能较内存session略低。
（3）保存在内存数据库（redis）
具备前两种的优点。缺点是需要额外部署redis，增加系统复杂性。
（1）保存在服务器内存
优点：速度快，
缺点：（1）如果使用的负载均衡，session在多个服务器之间不能共享，需要额外的同步机制；（2）一旦服务器重启，session就丢失了
（2）保存在数据库
优点：支持session共享和负载均衡；session能持久化存储。
缺点：性能较内存session略低。
（3）保存在内存数据库（redis）
具备前两种的优点。缺点是需要额外部署redis，增加系统复杂性。