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. >
