【问题标题】:How to manage request authorization with tokens?如何使用令牌管理请求授权?
【发布时间】:2018-08-17 08:57:55
【问题描述】:

我在开发过程中遇到了一些挑战,基本上我需要使用令牌授权用户去/调用某些页面/功能,这些页面可以设置为按需授权(也许在数据库)。

应用程序是用 Struts 1 制作的,所以我一直在想的只是使用过滤器拦截 URL,检查请求是否需要授权,通过电子邮件发送令牌并将用户重定向到“插入令牌”页面,如果引用者是令牌页面,则再次通过过滤器拦截并验证值,如果正确,则重定向到原始请求...

但是我不能简单地恢复之前的请求,而且过滤器拦截了 ServletRequest 和 Struts 有更详细的构造,所以我不能丢失动作或表单对象。

我不确定这是否是解决此需求的好方法,如果是,我需要将原始请求保留在内存中,我不知道该怎么做。

这是一个遗留项目,有很多页面和控制器,所以几乎不可能只通过每个方法进行验证。

我会接受任何建议,祝你有美好的一天! :)

编辑

为了添加更多上下文,该项目有许多使用 Struts 制作的表单,因此 Struts 在内部将 html 表单映射到 POJO,以将它们作为参数获取到操作(控制器)方法中:ActionMapping 和 ActionForm。创建过滤器时,我的参数是 ServletRequest、ServletResponse 和 FilterChain 对象,直接我没有 ActionMapping 或 ActionForm,但我知道它们是请求结构的一部分,所以我不知道如何获取它们直接,我正在尝试处理整个请求,因此存在安全性和大小问题,并且还因为我在执行重定向操作时不知道如何存储原始请求的副本

【问题讨论】:

  • 只是为了澄清:“将第一个 HTTP 请求作为一个整体存储,并在第二个请求之前在过滤器中检索/使用它”。这是正确的吗?
  • 第二个请求发生在用户最终发送重定向时询问的令牌时,一旦我执行验证,我需要让用户继续原始请求
  • 如果您对问题的答案感到满意,请将其关闭,以便社区的其他成员受益。
  • @HosseinPursultani 一旦我得到它,我会的,这个问题是我现在的首要任务,所以我仍在努力

标签: java servlets servlet-filters struts-1


【解决方案1】:

鉴于 Struts 喜欢传递的信息量,我很想将会话保存在安全的地方以供用户返回。 This post 谈到了类似的想法,尽管您可以只保留以令牌为密钥的会话。

意识到这个想法将取决于环境,例如预计用户以多快的速度返回令牌,以及需要扩展的用户总数。

【讨论】:

  • 好吧,用户不会一直发送令牌,但是我有点担心保存会话对象(在哪里),因为我需要在用户端保留一种会话 ID。你能给我一个更详细的例子来说明你的建议吗?
【解决方案2】:

我会考虑加密 HTTP cookie(如果您的应用程序隐私政策允许 cookie)。

您可以存储所需的信息以备后用,并在一段时间后将其过期。此外,您无需担心会话存储和扩展。在我看来,这符合要求。

话虽如此,您还需要考虑一些细节。特别是 cookie 加密。

更新

关于 cookie 中大对象的说明。创建大的 HTTP 标头并不总是一个好主意。大多数 Web 服务器甚至会强制设置最大标头大小(请参阅 Maximum on http header values?)。您需要以 Base64 编码序列化二进制数据,使其更大。

如果您的对象非常大(如 Struts 构造),无法放入 HTTP 标头。您可能也不希望将它们存储在内存会话中。如果可行,您可能需要考虑数据库支持的会话

Tomcat(如果这是您的 Web 容器)有一个 JDBCStore,您可以使用 configure 它。虽然对每个请求/响应都有一个数据库查询,但这并不是很好。

将所有会话存储在数据库中的另一种方法是仅将特定对象存储在数据库中并将其关联的密钥存储在 HTTP cookie 中。考虑到对象的大小,我可能会这样做。

这基本上是内存和速度之间的权衡。 (我不知道您的应用程序在资源和性能方面的确切要求)。

【讨论】:

  • 看起来很有趣,但是由于这是 Struts,我不是在谈论一些简单的参数,而是复杂的对象(动作、表单),我不太确定 cookie 可以处理这个,你有没有尝试过在用户端“存储”一个大对象?一个例子可能很方便
  • 我无法分辨我的头顶。通过在 cookie 中存储非常大的对象可能会出现问题。与会话相同,尤其是。内存中的会话。我会更新我的答案。
  • 好的,我也会更新问题以添加更多详细信息。
【解决方案3】:

在寻找合适的解决方案几天后,我决定改变想法,而不是重写(以非常不安全的方式)请求,我设计了一个两侧的解决方案,从前端我使用 JavaScript 拦截任何请求,我对 URL 进行初始验证,然后请求令牌,所以最后我发送了一个可以在过滤器中获取的附加参数,然后在完成验证后,我可以继续原始请求或创建重定向. 谢谢大家的时间和建议,我认为最好解释一下我做了什么,而不是把这个话题搁置一旁。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2020-06-24
    • 2020-10-18
    • 2021-08-02
    • 2018-08-25
    • 1970-01-01
    • 1970-01-01
    • 2019-07-04
    • 2019-10-01
    相关资源
    最近更新 更多