我知道这很有可能被标记为重复，但是找不到我要找的东西

这是一个常见问题，我敢肯定它有一些定义明确的最佳实践解决方案

背景

1. 单个页面的SaaS应用程序具有很多拖放功能，用户可以在不进行大量服务器通信的情况下与之交互

2. 服务器会话仅使用非持久会话cookie来保存用户对象

3. X小时后，会话在服务器上到期

4. 有些东西仅在登录时加载

问题

1. 用户在应用程序上工作，完成后，用户不会注销，只是保持浏览器保持打开状态
2. 用户超过X个小时后返回（会话在服务器上无效）
3. 用户无需服务器连接即可与应用进行交互（拖放内容，文本编辑...）
4. 仅在下一次服务器交互时（假设没有自动保存），用户将被抛出到登录页面，并丢失一些工作

可能的解决方案

这是我想到的一些解决方案，想听听是否还有其他解决方案，以及其中是否有任何根本性的错误。

1.永远不要注销用户

• 怎么样？保持长时间的会话，保持持久的cookie或javaScript“保持活动” ping
• 优点：用户无需担心任何事情，可以为他们解决问题
• 缺点：不符合PCI标准，不安全，并且需要进行开发更改，例如仅在用户登录时加载到会话的内容需要转移到pub子模型（侦听事件更改）或具有缓存超时。

2.本地存储

• 怎么样？如果注销，使用新的本地存储临时存储状态，重定向到登录页面，登录后永久保存
• 优点：也是“离线工作”支持的基础，而不仅仅是处理会话超时
• 缺点：难以实施，需要对数据树进行状态合并，并非所有浏览器都支持

3.自动保存

更改模型的每个用户操作都应立即保留（或通过某种客户端队列），例如，如果他们选中了复选框，更改了文本字段或拖放了某些东西，则一旦完成，就保留更改。

• 怎么样？使用MV **框架（Backbone.js / Knockout.js / Ember.js / Angular.js等）绑定模型，并坚持更改。
• 优点：似乎是一个干净的解决方案，只要用户处于活动状态，会话就处于活动状态，如果不坚持下去，则不会进行任何客户端工作。
• 缺点：会话超时丢失后，用户上一次执行的操作。

4.会话过期后注销用户

这可以有几种方法

1. 询问服务器“会话已过期”-这有点像22 /薛定inger的猫，因为服务器的唯一问题是延长了会话（重新启动超时），

   • 怎么样？要么有一个服务器支持这样的问题（我什么都不知道，但是我来自Java领域），或者可以只保留一张会话ID表，手动上一次访问时间，然后通过传递会话来询问服务器。 ID作为参数而非cookie的参数，我不确定这是否可行，但是听起来很危险，不安全且设计不佳。
   • 优点：如果服务器中有这种本机支持，这听起来像是一个干净，合理的问题（询问用户X是否仍然有会话，如果有则不进行更新）
   • 缺点：如果服务器不支持它（同样，我不知道是否有服务器或框架具有此功能），则解决方法可能会带来巨大的安全风险。

2. 我听说的一种解决方法是在服务器端进行一次简短会话，并在客户端ping保持活动状态ping，最多可以ping

   • 怎么样？服务器上的简短会话，客户端ping每个sessionTimeOut / 2，最大重试次数为Y。
   • 优点：可以解决问题，快速又脏
   • 缺点：感觉像黑客一样，自己处理会话续订而不是让服务器执行

3. 客户端计时器

   • 怎么样？在客户端上有一个计时器，并通过在每个请求上重新启动该计时器使其与服务器同步，以使其等于最大服务器会话超时减去某些填充，在用户未向服务器发送任何请求后，UI会显示“会话为即将超时，您要继续吗？” （就像您在网上银行一样）

   • 优点：解决问题

   • 缺点：除了需要确保同步正常工作外，别无其他

问题

我可能在上述分析中缺少某些内容，可能有一些愚蠢的错误，希望您能提供帮助来纠正它们。为此，我还有什么其他解决方案？

我认为最常见的简单解决方案是，您在客户端上设置一个计时器，该计时器在正常超时窗口的特定部分过去之后显示一条消息，然后如果会话不采取任何措施，则在会话到期之前立即将其强制注销。

本地存储和自动保存会带来一些事务问题，保存的真正含义是什么。我参与过许多项目，当用户群不了解其背后的机制时，这比实际值得的麻烦更多。

在法规允许的范围内，永远都无法注销，但是如果有人意外注销，您将无法正确处理所发生的事情，这将导致您陷入错误，并且如果有很多需要跟踪的事项，那么所有的州业务都会变得难以维护一个“活跃”用户。

我听说的一种解决方法是在服务器端进行一次简短会话，并进行keep> alive客户端ping操作，该操作最多可以

怎么样？服务器上的会话较短，客户端每次会话ping一次，每次ping> 2，最大>重试Y。优点：可以解决问题，又快又脏

我认为这是最好的解决方案。为什么您认为它是“肮脏的骇客”？

这使得必须要做的事情。当用户使用程序时，会话将保持打开状态。

用户停止使用该程序后，该会话将关闭。

足够简单即可实施。

如果我理解正确的问题，那么确实需要什么。

我实际上正在创建一个处理此问题的应用程序。

我首先使用Django，Guradian和Tastypie创建RESTful服务。它仅使用API​​KEY进行身份验证，对对象的授权由Guardian处理。

django应用程序只有一个模板视图urlconf，可加载base.html，即

在客户端，我使用Angular创建了一个应用程序。

就身份验证而言，有一个http-auth-interceptor侦听401响应。

收到401后，它将缓冲传出的请求并触发“需要登录”事件。这可能会发生几次。

我有一个模态弹出窗口，其中包含一个登录表单，该表单会在听到“需要登录”事件时显示，并执行一个返回用户资源（JSON捆绑包）的登录，该资源也将包含APIKEY。

现在使用Authorization http标头中包含的APIKEY重放以前导致401响应的所有缓冲请求。

我使用另一个角度服务/工厂来管理本地存储json数据，这就是我存储用户名和apikey的地方。

剩下唯一需要解决的难题是如何保护该信息，以及如何对该信息实施超时。

也许使用来自最后一个有效http请求的时间戳检查。

就我而言，我使用的是类似于4.1的东西。用户登录后，REST API会以设置的间隔对服务器发出非常轻巧的角度驱动的AJAX json请求。由于安全性要求，专有UI预期服务器将为用户维护一个会话，该会话在服务器端存储一些受保护的信息，模板，数据等。从安全角度来看，这仍然是我的首选方法。当处理敏感数据（不仅是哈希密码等）时，IMO将其客户端存储在本地存储中等比服务器端带来更大的风险（我敢肯定有人会与我辩论）。第三方在与系统通信时使用相同的API，但必须在每个请求上发送身份验证凭据。

服务器上的会话确实具有一个最大空闲生存期，并且会话存储引擎是memcached（它还具有一个最大生存期，此时内存会话将被标记为已过期）。生存期只需要大于您在应用程序中抽象的会话生存期即可（不必花很多时间）。EG就服务器而言，会话可能要等到空闲48小时才能到期，但是您的代码控制了实际寿命。如果生存期过长，这可能会导致资源问题，并且您在管理会话方面做得很差。

就我而言，不同的用户可以根据他们在组织中的角色而具有不同的会话空闲超时。服务器对会话生存期设置了最大限制，但是只要用户定义的限制小于这些限制，它就可以正常工作。服务器使会话过期后，这将是一个有争议的问题，因为会话过期过程已由应用程序正常处理。这是我构建的那种业务应用程序的要求。

一旦用户会话闲置并处于应用程序指定的阈值之内，API就会指示UI显示倒数对话框（就像银行一样），并且一旦它距到期时间在特定的时间范围内，它就会正常显示将用户注销。此功能在浏览器窗口之间仍然存在（因为服务器处于控制状态），并且任何窗口上的空闲事件都将启动优美的计时器和自动注销过程（并使它们保持同步）。

如果偶然的会话过期（会话被转储到memcached上），则下一个影响服务器的请求将通知用户并将其移回方形（很少发生，但是可以）。