Well, as for the SecurityContext: 1. Set up a session-scoped ASO which can hold the current user's id. 2. Set up a SecurityContext service in HiveMind (threaded service lifecycle model of course). Inject the ApplicationStateManager into it (just provide a setter) so that it can look up the ASO you created in step 1. 3. Create a lazy-loaded getter for the actual user object (which contains a way to ask what permissions/privileges/roles they have). This usually involves checking that a property is null and then calling a DAO to go get the user object from the database.
-----Original Message----- From: Andreas Bulling [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Bulling Sent: Tuesday, April 18, 2006 7:03 AM To: Tapestry users Subject: Re: ICallback/Session problem Hi James, On 18. Apr 2006 - 06:55:12, James Carman wrote: | That's how I do it. I store the user-id in the session inside one of my | ASOs. Then, I have a threaded service called SecurityContext which actually | will lazily load the actual user object during the request cycle if it's | asked for by someone (like a security interceptor or something). in only this four lines you mention two things I'm highly interested in: The SecurityContext and the SecurtyInterceptor. As I wrote in one of my former posts I'm in search of a security concept for my application and those two things at least sound as if they are what I also thought of ;) Would you mind to provide further information about how you implemented them or even some example/the code? Kind regards, Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
