struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <ahardy.str...@cyberspaceroad.com>
Subject Re: security framework!!!
Date Sun, 14 Mar 2004 23:28:13 GMT
You mean you don't want to force the user to log out and back in again? 
I would have thought that was a reasonable demand since they are 
effectively changing their identity.

Your HttpServletRequest wrapper sounds OK as a solution though.

Adam

On 03/14/2004 03:51 PM David Friedman wrote:
> Adam,
> 
> I want to integrate everything with roles (for using actions and jsp tags)
> so I'm stuck, after container authentication, having a non-changeable
> Principal object within Tomcat: their Coyote HttpServletRequest wrapping
> class prevents the use of setUserPrincipal.  All of my research on Tomcat (4
> or 5) suggests a filter-based wrapper for the HttpServletRequest object is
> the only way to go to be able to set the UserPrincipal from within my action
> so I could replace the Principal (as the admin becomes the reseller becomes
> the customer becomes the manager becomes the user account, etc. and possibly
> backs out each level one by one).
> 
> Can you suggest any other avenues or theories for me to investigate since my
> research has resulted in only that one workable solution?  Hints
> appreciated. :)
> 
> Regards,
> David
> 
> -----Original Message-----
> From: Adam Hardy [mailto:ahardy.struts@cyberspaceroad.com]
> Sent: Sunday, March 14, 2004 5:21 AM
> To: Struts Users Mailing List
> Subject: Re: security framework!!!
> 
> 
> On 03/13/2004 05:48 PM David Friedman wrote:
> 
>>My bigger problem is my scenario, which no one supports.  I'd like to
> 
> allow
> 
>>manager accounts to become one of if it's sub-accounts.  My system would
>>support at least 5 levels where 4 could 'drill down' and back up again:
>>admin, reseller, client, manager, employee (bottom feeder, no managerial
>>tools and no popping into their accounts).  Since there is no easily way
> 
> to
> 
>>push/pop or even set (then I could use my own internal stack) a
>>UserPrincipal object, I'm thinking of using something a bit like
>>SecurityFilter:
> 
> 
> I'm not sure why the standard container-managed security roles don't
> meet your requirements.
> 
> You want a manager to be able to set himself to another role? Sounds
> like a design issue. Obviously the manager is also going to need to set
> himself back to his normal role again?
> 
> I would use extra roles to allow changing roles. The manager can assign
> himself whatever standard role he likes depending on his 'extra' roles.
> This would change the info in your realm and he would have to log out
> and back in again.
> 
> Or have I got the wrong end of the stick?
> 
> Adam
> --
> struts 1.1 + tomcat 5.0.16 + java 1.4.2
> Linux 2.4.20 Debian
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 
> 


-- 
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message