【发布时间】:2018-05-19 18:27:13
【问题描述】:
这里的代码显示,当会话超时时,devise 将重定向到当前请求的路径(由timeoutable 模块检查并强制执行):https://github.com/plataformatec/devise/blob/master/lib/devise/failure_app.rb#L120
attempted_path 在调用失败应用之前由warden 设置。
问题是:为什么要设计重定向回当前请求的路径本身?如果会话超时,那么客户端是否应该被重定向到当前实体的登录页面(User 或 Admin 或其他)?
如果未设置attempted_path,它确实使用scope_url。但我不明白为什么要再次重定向到当前请求的路径?这不会导致重定向循环吗?
这个重定向循环实际上发生在 Rails 管理员身上。如果我在 Rails 管理员中为我正在验证的模型启用timeoutable,那么在会话超时后,任何请求都会导致重定向循环。
那么有人可以向我解释为什么要重定向到attempted_path 吗?坐席服务于什么用例?
其他信息 这是我想到的两个流程。
应该如何
- 用户尝试访问页面 x。会话超时。
- 用户被重定向到登录页面
- 用户登录
- 用户被重定向回页面 x
目前情况如何
- 用户尝试访问页面 x。会话超时。
- 用户被重定向到第 x 页。
它会重复循环,直到浏览器显示“网站未正确重定向”。
【问题讨论】:
-
其设置为将每个用户重定向到登录/注册页面。循环是这样的:检查warden是否用户会话太长,如果是,则销毁它,重定向到尝试的页面,如果用户在没有登录的情况下无法访问它,则重定向到登录页面。最后一次重定向是因为 authenticate_user! 而发生的,它应该始终在所有需要身份验证的站点上实现,否则您将得到您与管理员描述的循环。如果没有重定向到尝试的路径,设计将不知道如何重定向到登录页面。
-
@Prometheus 谢谢。我也发现了问题并解决了。将我的发现放在下面的答案中。一个问题仍然存在:为什么设计在超时的情况下无法知道登录页面 url?为什么需要额外重定向到
attempted_path?这不再是一个障碍,但肯定会非常有助于理解。
标签: ruby-on-rails devise