Hi Jack,
On Thu, May 19, 2011 at 9:15 AM, juminoz <[email protected]> wrote:
> Hi Les,
>
> Thanks for the pointer.
>
> Does manually creating a subject also create a put a session in the cache?
Nope - a session is only created (currently) when calling
subject.getSession() or subject.login.
> The reasons I wanted the thread unbound right after login are as follow:
>
> 1) Request to login does nothing more than just a login. If the
> session/subject can be cache by manually creating the subject, I think that
> may work out better as you suggested.
If I understand your scenario correctly, it doesn't matter what type
of request is being executed. If your framework code transparently
creates, binds and then unbinds a Subject for every request (e.g.
exactly as the ShiroFilter does for a web app), it will work in all
cases, login or not.
To illustrate, this will login and cleanup the thread immediately after login:
//build the subject however you want from the message or request,
//perhaps using a sessionId.
Subject subject = new Subject.Builder().whatever....buildSubject();
final AuthenticationToken token = //get/create token based on the request
subject.execute(new Runnable() {
public void run() {
SecurityUtils.getSubject().login(token);
}
});
//thread is 'clean' here
But the problem with this code, from a framework perspective at least,
is that it will *only* perform a login. It will not work for any
other type of request or message. Without understanding your scenario
further, one would assume that you want to be able to enable security
while processing any request or message - not just the login ones. If
that is the case, the above code is not ideal since it can't handle
other types of requests.
HTH,
Les
