I am far from being an Acegi expert, so take this FWIW.
Peter Kharchenko <[EMAIL PROTECTED]> writes:
> That's what I am currently doing. The ugliness comes in the first
> request, when the Context has not yet been placed into the session
> (since the filter does it at the end of the request processing).
I wouldn't have thought you'd need to look in the session at all. By
the time request processing has reached the application the Context
(the ThreadLocal, that is) should have already been setup, either by
the authenticator or from the session.
> Since HttpSessionContextIntegrationFilter has to be placed before
> authentication processing filters, I ended up inserting a trivial
> integration filter at the end of the filter chain that puts Context
> into a request attribute. It works, I was just wondering if there's a
> better way.
I guess I don't get it. Wouldn't you have something like
request processing starts
populate the context (ThreadLocal) from:
the session, or
the authentication method
(everything above here is acegi, below is the app)
for each task
copy the context into the task thread (*)
run the task with the correct context
maybe (*) is the hard part. you'd certainly have to have an interface
to your workers such that the workers can receive both the task and
the security context, and do the right thing with the context before
starting on the task.
--
joe
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
