Actually I think its probably good that you dont need to bind to a
thread by default, even in webapps, threadbound behaviour can be a bad idea.
For non blocking, async behaviour for example. There are relatively few
worker threads available and in many cases its unreasonable to tie up a
thread for a single subject for the life of a request. One thread may
handle many different users more or less simultaneously (waiting for
callbacks etc), so trying to manage where to bind & rebind threadlocals
gets messy.
the way I am using Shiro atm in a standalone app(havent updated yet), is
from an initial MethodInterceptor, I build a Subject from a given
sessionID,then I use the
subject.execute(new Callable() {
public Object call() throws Exception {
try {
return invocation.proceed();
...
I use this just because it nicely decouples the interceptor from the
rest of my code and my app feels like a plain old webapp at this point,
I also happen to want a new thread at this point so its convenient.
but in the invoked procedure I grab the subject and hand it around no
longer using the threadlocal reference.
eventually the callables' returned future is invoked and we're done.
cheers.
Les Hazlewood wrote:
Hi Al (and any other standalone application users),
This is somewhat of a long email, but your answers will give us
direction how to present a solution for all Shiro users writing
standalone applications - please read and reply if you can!
Yes, we made some changes yesterday with how subject binding occurs
after creation. The fix you used probably works for your environment
(and might be totally fine in your case), but we can't say it is valid
in all cases, which is why the behavior was changed.
The issue here is that automatically binding to a ThreadLocal is maybe
not the best approach for all environments. In a web app, this makes
sense because there is framework code that will bind and unbind to the
thread before and after request processing, respectively. We can
always guarantee that the thread will be cleaned up after it is done
executing or even when it throws an exception - so when that thread is
used to process a different request, we can be sure it isn't
'polluted' with the Subject from a previous request.
It is hard to make that guarantee for a standalone application. I
mean, sure, we could bind the subject to the thread like you did to
resolve your issue, but is it ok to keep that subject associated with
that thread forever? If not, when should it be cleaned? It's
impossible for us to answer that question for custom applications.
For example, if we did the thread binding, and someone was writing a
custom server and wanted to use Shiro to secure their server, then we
certainly shouldn't bind to the thread automatically - the server
should have some mechanism that performs the binding/unbinding for
every request (RMI, REST, etc) that it receives (probably identical to
our web approach).
So, my question to you is - do you have any ideas of a good way this
would work? How do you manage threads in your application? After you
call subject.login, are any other threads that would need access to
the subject?
Your answers (or those from anyone else!) would greatly help us
support standalone applications in a much cleaner manner. Please let
us know!
Thanks for any feedback,
Les
On Fri, Feb 19, 2010 at 7:42 AM, aloleary <[email protected]> wrote:
I seem to be able to remedy with the following on startup:
ThreadContext.bind(currentUser);
but again wondering if this is something that recently changed or if it
points to some bad config on my side
thanks
--
View this message in context:
http://n2.nabble.com/SecurityUtils-getSubject-issue-tp4597560p4597613.html
Sent from the Shiro User mailing list archive at Nabble.com.
