A wrench into this serializable proxy concept is the WebSubject interface - a sub-interface of Subject that is created as a result of an inbound request. If SecurityUtils.getSubject() returns a serializable proxy, what type would be returned? A Subject? or WebSubject?
People (and Shiro) often check for a WebSubject instance to get access to the originating request/response pair, and so it seems like in a web environment, SecurityUtils.getSubject() should return WebSubject instances to allow this functionality to continue to work. But if serializing and deserializing a WebSubject proxy, and the underlying ThreadLocal Subject instance is not a WebSubject (e.g. maybe the Subject instance is now executing on a remote machine in a JMS processing queue) - the Subject methods would still be valid, but the WebSubject methods would not. This is clearly an invalid state and would result in an exception. That would cause confusion and doesn't sound very 'Shiroy'. Food for thought... On Mon, Jan 9, 2012 at 2:57 PM, Les Hazlewood <[email protected]> wrote: > Yes, thanks Martin for reporting this. > > I believe your marking the Subject injection points in the code as > transient makes sense and is more 'correct' based on Shiro's current > implementation. Subject instances can come and go in an application > depending on who is currently executing the backing thread. This > sounds like a strong reflection of the word transient to me: > > For example, if you were to serialize a component with a referenced > Subject and then reconstitute that component later on, does it make > sense for that exact subject instance (with its identity and session > state) to pick up from where it left off? I would assume not, but > maybe it does - I'm not sure. Such a scenario is currently undefined > for Shiro. > > I think this issue surfaces from a thin line in interpretation: > Subject as a term in general means 'the currently executing end-user'. > But the actual runtime Subject _instance reference_ (memory pointer) > means a very specific executing end-user at that exact moment in time. > > Now, perhaps the best way to solve this is by having > SecurityUtils.getSubject() return a serializable proxy: you can > retain the returned Subject instance and serialize it. But 'under the > hood' it delegates to the 'real' logic to look up the instance from > the thread at runtime. That way the proxy serializes safely, but > method calls on it will always reflect the underlying runtime > reference. > > We could do this, and I think it would retain backwards-compatible > behavior, but it creates one question: > > When deserializing the Subject proxy, and that proxy looks for a > Subject on the thread at runtime, but one does not exist (due to > erroneous configuration, or unexpected environment, etc), we throw > something akin to an IllegalStateException? Is this more desirable > than asking the developer to think the runtime reference's transient > nature? > > If anyone has any thoughts on this, please contribute. > > Cheers, > > -- > Les Hazlewood > CTO, Katasoft | http://www.katasoft.com | 888.391.5282 > twitter: @lhazlewood | http://twitter.com/lhazlewood > katasoft blog: http://www.katasoft.com/blogs/lhazlewood > personal blog: http://leshazlewood.com
