On Wed, Dec 31, 2008 at 10:40 AM, Jeremy Haile <[email protected]> wrote: > > This may even eliminate the need entirely for a Thread-bound ServletRequest >> and ServletResponse. They were originally bound to the thread >> specifically >> to aid in Subject construction. But I'd have to see whether or not a >> thread-bound request/response is used in other ways before we can >> definitively say binding is not necessary anymore. >> > > Not totally accurate in my opinion - the ThreadLocal is used so that we can > access the subject anywhere without having to get access to JSecurity > objects, such as the SecurityManager. This to me implies one of two things > a) you're proposing we store the Subject in the session or b) the security > manager is pulling stuff out of the session and constructing a subject every > time you ask for it.
I didnt' say anything about how the Subject is stored/accessed :). I was talking about a "Thread-bound ServletRequest and ServletResponse". But, after thinking about this, and based on your reply, then maybe we need to still do that in a web environment so the WebAccessor has something to pull from. Consider this alternate implementation of JSecurityFilter's doFilterInternal method. Hopefully it will illustrate my thoughts: HttpServletRequest request = (HttpServletRequest) servletRequest; HttpServletResponse response = (HttpServletResponse) servletResponse; //here is where we bound the InetAddress - maybe not necessary anymore //construct JSecurityHttpServletRequest/JSecurityHttpServletResponse same as in //existing implementation //here is where we called WebUtils.bind(request)/.bind(response) - maybe not necessary anymore. Subject subject = getSecurityManager().getSubject( new HttpPair(request, response) ); ThreadContext.bind(subject); ThreadContext.bind(getSecurityManager()); FilterChain chain = getConfiguration().getChain(request, response, origChain); //rest of the implementation stays the same... Again, I don't know if this is the way it should work, its just an idea. Maybe getSubject( new HttpPair(request, response) ); is never called. Maybe the request and the response ARE bound to the thread, and the WebAccessor implementation knows to pull them off of the thread when building the subject upon the very first request to securityManager.getSubject(). Maybe that's the cleanest way to go - I dunno yet ;) Automatically assuming a Thread-based model causes problems that could be >> easily mitigated by this approach (for example, in a daemon environment, >> when the thread executing isn't the same as a user request). Lots of >> flexibility there. >> > > Well - there are ways to support a thread-based model, even for daemon > threads. And I think daemon threads are even harder to support by assuming > a request/response based model. I'm not assuming any model - that's up to the Accessor implementation. One implementation could use the ThreadContext. Another can use Http request/response pairs. Another can pull it from a file if it is a desktop app. Sure the daemon-compatible implementation can use the ThreadContext - I'm just saying that the SecurityManager doesn't need to know that - it is up to the Accessor implementation. But, let's say we leave the Accessor out of it. We'll probably need securityManager.getSubject( initData) just to suport runAs/assumedIdentity, where 'initData' is the identiy being assumed...
