On Wed, May 18, 2011 at 6:42 PM, juminoz <[email protected]> wrote:
> Yes, I think I potentially can do it that way, but I will need to look into
> how to do it with the constraints I have currently.
>
> What I'm doing is building a framework so that developer can use it to
> develop their applications. Doing it my way definitely seems risky since
> it's possible that developer forget to unbind the thread after each task.
>
> Anyway, it seems like I need to unbind the subject from the thread right
> away after login.
Why would you ever do this? Most people want the authenticated
Subject instance available for the rest of the request so they can use
it to perform security checks at any point during the request.
In any event, in a non-web request/message scenario, nothing is bound
to the thread by default. If you call SecurityUtils.getSubject()
however, it will automatically (lazily) create a Subject instance and
bind it to the thread if one does not yet exist.
If you don't want anything bound to the thread in a framework
development scenario, don't use SecurityUtils to set-up the initial
Subject instance. Instead, it would work like the following:
Message message = //get message somehow
//nothing is bound to the thread at this point
//build a subject instance based on the incoming message
//the 'buildSubject' method would use Subject.Builder to build the
Subject instance
Subject subject = buildSubject(message);
//nothing is bound to the thread at this point
subject.execute(new Runnable() {
public void run() {
//the Subject is bound to the thread here!
}
});
//nothing is bound to the thread at this point.
Notice how SecurityUtils was not used. SecurityUtils is to make the
lives of application developers easy. Framework developers will not
use it that often however, and instead rely on building the subject
and calling execute as shown above.
HTH,
Les
