Catalyst 应用程序的最佳操作持久性技术是什么？

Question

我正在编写一个 Catalyst 应用程序，该应用程序需要相当短的会话过期时间（15 分钟）。 我正在使用标准的 Catalyst 框架身份验证模块，因此用户数据存储在会话中 - 即，当您的会话过期时，您将被注销。

此应用程序的许多使用都需要超过 15 分钟才能完成，因此用户经常会提交表单，却发现他们的会话状态消失了，并且需要重新登录。

如果发生这种情况，我想保留原始状态表单提交，如果登录成功，则继续进行表单提交，就像会话未过期一样。

我已经通过控制器中的 auto() 方法处理身份验证内容 - 如果您请求需要身份验证的操作并且当前未登录，您将被重定向到 login() 方法，该方法显示登录表单，然后在提交后对其进行处理。 当 auto 方法重定向到 login() 时，似乎应该可以存储请求和任何表单参数，然后在 login() 成功时将它们拉出来 - 但我不完全确定最好的方法以通用/标准/可重用的方式获取或存储此信息的方法。 （我正在考虑将其存储在会话中，然后在将其拉出后将其删除；如果这看起来是一个坏主意，那就需要解决其他问题。）

是否有标准的“最佳实践”或食谱方法可以做到这一点？

（一个问题：这些表格是通过 POST 提交的。）

Answer 1

我不禁想到，在一个通常需要 15 分钟以上操作之间间隔的应用程序中强制执行 15 分钟超时存在根本性缺陷。

尽管如此，我还是会考虑重写 Catalyst::Plugin::Session->delete_session 方法，以便 $c->request-> 的任何内容都可以被删除。 body_parameters 被序列化并保存（可能保存到数据库）以供以后恢复。 您可能需要对 POST 参数进行一些基本检查，以确保它们符合您的预期。

同样，create_session 需要负责从数据库中提取这些数据，并使其可用于原始表单操作。

这看起来确实是一个混乱的情况，我倾向于重复我的第一句话...

更新：

无论您使用 delete_session 还是 auto，矛盾的问题仍然存在：您无法将此信息存储在会话中，因为超时事件会破坏会话。 您必须将其存储在更永久的位置，以便它在会话重新初始化后仍然存在。 Catalyst::Plugin::Session 本身正在使用 可存储，并且您应该能够使用以下内容：

use Storable;
...
sub auto {
    ...
    unless (...) { #ie don't do this if processing the login action
        my $formitems = freeze $c->request->body_parameters;
        my $freezer = $rs->update_or_create(
              {user => $c->user, formitems => $formitems} );
        # Don't quote me on the exact syntax, I don't use DBIx::Class
    }
    ...
    my $formitems = $c->request->body_parameters
                  || thaw $rs->find({$user => $c->user})->formitems
                  || {} ;
    # use formitems instead of $c->request->body_parameters from here on in

基础表可能具有 (user CHAR(x), formitems TEXT) 或类似内容。 也许是一个时间戳，这样就不会恢复任何过时的内容。 您可能还想存储正在处理的操作，以确保检索到的表单项属于正确的表单。 您比我更了解您的应用程序的问题。

Answer 2

我会将表单数据存储为模型中的某种每用户数据。

Catalyst::Plugin::Session::PerUser 是这样做的一种方法（尽管有点黑客）。 我建议仅使用会话插件进行身份验证并将所有状态信息存储在存储用户数据的模型中。

我完全同意 RET 的观点，即 15 分钟的限制在这种情况下似乎确实适得其反。

Answer 3

我在 CPAN 中搜索完全不相关的内容时发现了这一点。

Catalyst::Plugin::Wizard 旨在完全满足您的需求。 该文档表明它可以重定向到登录页面，同时保留先前操作的状态。

注意：我没有使用过它，所以不能保证它的有效性。

Answer 4

最后，我们最终在 auto() 中获取待处理的请求（URL+参数），对其进行序列化和加密，并通过登录页面上的隐藏表单元素传递它。 如果我们收到填充了隐藏元素的登录请求，我们将对其进行解密和反序列化，然后进行适当的重定向（确保通过标准的“此用户可以执行此操作吗”代码路径）。

Answer 5

您始终可以在客户端上使用一些 javascript，通过每隔几分钟发出一个小请求来防止会话过期。

或者，您可以在发布表单之前让 AJAX 检查活动会话，并在需要时向用户显示新的登录框。