That's good advice. Thanks. I currently am "required" to run Tomcat 3.2.3 so I decided to go the "hack path" and include my security in struts and hide all my views(jsp) behind command style urls (no *.do). Yet my code is flexible enough to take advantage of the container managed security when I move up to tomcat 4.0 (servlet 2.3/jsp 1.2). Thanks for your direction.
Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -----Original Message----- From: Taylor Cowan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 7:18 AM To: Struts Developers List Subject: RE: role based actions Struts is a J2EE add on, thus it should only be aware of J2EE concepts like "roles". J2EE provides security through the app server, and the concrete security scheme may be ldap, jdbc, or other means. Struts doesn't need security, it just makes use of J2EE security. I was just looking over Tomcat and it can be configured to use LDAP. Most other app servers should provide that as well. If you really do need to implement your own security, it would be better to add this at the app server level, not struts. Taylor -----Original Message----- From: Phase Communcations [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 9:54 AM To: Struts Developers List Subject: RE: role based actions The ldap portion is under development. It will be a bit. My code is a struts centric security at this point. I am experimenting with extending it to support ldap. I can still show you the code for the security if you would like. Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -----Original Message----- From: Dr. BaTien Duong [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 11, 2001 5:53 PM To: Struts Developers List Subject: Re: role based actions Brandon: I am interested in your code as we are working on Struts, ldap, and Java single SignOn technology. [EMAIL PROTECTED] ----- Original Message ----- From: "Phase Communcations" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, December 11, 2001 4:43 PM Subject: RE: role based actions > One last thing. When a security check happens and the user is forwarded to > the login. Their desired destination is stored and once their security is > verified they are forwarded on to that page. > > -----Original Message----- > From: Phase Communcations [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 11, 2001 4:40 PM > To: Struts Developers List > Subject: RE: role based actions > > > In my code I extended the action class (not the action servlet) and required > that group access be established on a per extended action class basis. > > Defined within my struts-config file in my action class definitions I use an > extra attribute(s): > > <set-property property="group" value="agroup" /> > > There is a security check within the extended action class that uses an > extended ActionMapping to retrieve the "group" property and checks it > against the users information (in a database). If the user belongs to the > proper group or one of the groups defined then it allows them access to that > action/area with their assigned role and permissions. If the security check > fails, they are routed to a login page. > > The other thing that it does is it stores role and permission information in > a bean so that security information can be used to define the view as well. > > I opted out of the container managed security because I was working under > Tomcat 3.2.3 and am trying to create a more independent security model. This > model also works well for me because I use the command line url format for > mapping to my action classes and none of my views are available but through > action classes (except index.jsp). > > I would be happy to share my code if anyone is interested. I think it is > flexible enough that it could be incorporated into an ldap system. I have > been confeing with a colleague who is working on struts interacting with > ldap for security and profile management. > > Anyways if you like the idea of security being managed from the action class > and don't expose your views but through action mappings. This might be a > good solution > > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > [EMAIL PROTECTED] > http://www.phase.ws > > > -----Original Message----- > From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig > R. McClanahan > Sent: Tuesday, December 11, 2001 10:16 AM > To: Struts Developers List > Subject: Re: role based actions > > > > > On Tue, 11 Dec 2001 [EMAIL PROTECTED] wrote: > > > Date: Tue, 11 Dec 2001 10:27:52 -0500 > > From: [EMAIL PROTECTED] > > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: role based actions > > > > > > I am a struts "newbie" so I apologize in advance if this topic has already > > beaten to death... > > > > ~~~ > > > > I noticed role-based actions on the pending tasks list. > > Adding this (and a few of the other recent enhancements) to Struts 1.1 is > definitely on *my* list. I will have some time to do so between Christmas > and New Years. > > Craig McClanahan > > > > > Can anyone comment on the status and scope of this effort? (link was a > dead > > end) > > > > The description points to role being driven by security, seems the role > will > > be detected and then dispatches to the proper action? points to assoc'd > form > > through config? > > > > Is this intended to be used for personalization to the extent where a > person > > of one role gets a different view, can user customize their view? > > > > Does this provide a place holder for that kind of functionality v. any > > particular "built in" functionality? > > > > Thanks, sorry if the questions were a little obtuse. > > > > -Rick Vaillancourt > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
