java的sessionid_java – 使用sessionId或用户名密码进行Shiro验证

Shiro’s Session support is much simpler to use and manage than either of these two [web container or EJB Stateful Session Beans] mechanisms, and it is available in any application, regardless of container.

例如

Subject currentUser = SecurityUtils.getSubject();

Session session = currentUser.getSession();

session.setAttribute( "someKey", someValue);

引用自the doc：getSession调用在任何应用程序中工作，甚至非Web应用程序

给客户端真正的sessionId还是应该发送某种类型的sessionToken(在服务器端解析为sessionId)，这是不错的做法？

发送普通sessionId是一个坏主意。特别地，如果您通过未加密的网络发送数据。要么使用像HTTPS这样的东西，要么使用NONCE。

而且，一个附注，如果通过http / s POST数据，而不是在URL。

如何使用sessionId(客户端应该在本地存储)登录主题？

你的意思是，一旦你有会话ID，你如何验证该主题？你可以简单地说，

从文档，

Subject requestSubject = new Subject.Builder().sessionId(sessionId).buildSubject();

在进行这种认证之前还有其他需要知道的事情吗？

是。

更新

关于该主题认证部分 – 它会使新创建的主题成为当前认证的主题吗？如果没有，我该如何使其成为“当前”科目？

如果你在谈论新的Subject.Builder()。sessionId(sessionId).buildSubject()，它不会。而我不知道如何设置为currentUser为线程。 Shiro的JavaDoc说，

[this way] returned Subject instance is not automatically bound to the application (thread) for further use. That is, SecurityUtils.getSubject() will not automatically return the same instance as what is returned by the builder. It is up to the framework developer to bind the built Subject for continued use if desired.

所以，这是由你自己在当前线程或进一步使用中绑定主题。

如果你担心SecurityUtils.getSubject();事情很好，在web-container上下文中，它使用简单的cookie来存储你的会话数据。当您的请求通过Shiro过滤器时，它附加当前主题以请求其生命周期(当前线程)。而当您作为getSubject()时，它只需从请求中获取主题。我发现一个有趣的线程here。

关于nonce部分：如果他给我一些哈希而不是他的sessionId – 我将无法解码它以获得真正的sessionId(以授权他)。我在这里遗漏了什么吗？

随便的部分 – 这是一个痛苦的脖子。现在重新思考，我认为做NONCE只是过度杀戮。让我解释一下，反正，

>用户首次使用用户名和密码进行登录。设置userid，nonce(例如UUID)和HASH(sessionID随机数)，在客户端调用它hash1。说，在cookie。将这个随机数存储在服务器端，可以在DB中或在Map中以user_id< - >现时，SESSION_ID

>在后续请求中，确保您传回userid，随机数和HASH。

>在服务器端，您首先要做的是验证请求。根据客户端发送的user_id，将sessionId和nonce存储在hashmap或DB中。创建哈希，HASH(sessionId_from_db nonce_from_db)，调用hash2。

>现在，如果hash1与hash2匹配，则可以验证请求，并且由于您已经在服务器端存储了当前sessionId，所以可以使用它。请求完成后，在cookie和服务器端设置新的随机数。

如果您通过1 – 4，您将意识到您不需要Shiro进行身份验证。 (：

所以，我回复我的话，NONCE在这种情况下不适用，除非你对性能的安全性太过分了。

为什么MITM攻击对我有影响？我的客户端(javascript ajax代码)通过ajax从服务器获取数据。所以我不认为我应该以任何方式关心MITM。

我认为这对你来说很重要。 MITM攻击意味着您的请求/响应通过机器(MITM)链接到您的路由器。如果这是一个未加密的请求，这是MITM的所有纯文本。他可以看到您的所有请求，并可能欺骗请求，并可能会劫持会话。让我找一些例子…. http://michael-coates.blogspot.com/2010/03/man-in-middle-attack-explained.html