Thank you very much for your time Erik, i'll try to get some study around it!!!
I don't know if it's possible (probably not, i know...) , but if you could send me your LogonAction class (and associated stuff) would awsome! But i you can't, that's allrigth, i completely understand! Regards, Leandro. --- Erik Weber <[EMAIL PROTECTED]> escreveu: > Sorry, by "hand-rolled" I just mean one that is > written specifically for > the application (written by you). > > The general idea is something like this: > > Make a BaseAction class. > > Implement a checkLogin method in the BaseAction > class that looks in the > current request's HttpSession for a "User" object, > which you would have > placed into the session in your LoginAction. > Implement a checkPermission method in the BaseAction > class that looks in > the current HttpSession for a role associated with > the user (maybe this > is part of the "User" object) that matches the role > required for the > current request (or you can go as fine-grained as > you want, with many > different permissions to check for a single request) > to be granted. > > All your Action classes extend the BaseAction class. > They can invoke the > checkLogin and/or the checkPermission methods at the > beginning of the > execute method to decide whether/how to proceed. > > Write a LoginAction class that sets the "User" > action, along with > permissions, roles, etc., whatever else is needed in > your checkLogin and > checkPermission methods, in the session after login > has succeeded (you > have taken the entered username and password and > matched them > successfully against a username and password > combination in your > database -- typically in a USERS table). > > Write a Logout Action that invalidates the current > session. > > Alternatively, you could check the login and the > permissions the same > way, but in a sublass of the Struts > RequestProcessor, or in a Servlet > Filter, instead of in a BaseAction class. > > If you want to go with container-managed security > and you can use > Tomcat, try this (you should probably read it > anyway). > > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/realm-howto.html > > I also suggest you read the security section of the > J2EE tutorial, and > the security sections of the JSP and Servlet > specifications. > > If you go with container-managed security, it's real > easy to allow/deny > entire JSPs, but you still may need to implement > finer-grained > permissions checks on your own if you need to, for > example, show/hide > links on a page based on permissions. > > Erik > > Leandro Melo wrote: > > >Erik, > >i don't quite understand what you call a > hand-rolled > >java component (maybe because of my english). > >Anyway, it seems to me that you're not using JAAS > to > >completely control application's security, are u? > >I don't know if it possible, but if so, would you > post > >your setup and basic classes? > >I'm very very new at security stuff... > >Anyway, i cleared out a lot of things for me. > > > >Thanks, > >Leandro. > > > > > > --- Erik Weber <[EMAIL PROTECTED]> > escreveu: > > > > > >>I don't really consider myself an expert here, but > I > >>dare say that there > >>are a lot of webapps deployed out there using > >>programmatic (hand-rolled) > >>security successfully. I have used the approach > with > >>success. What > >>exactly the advantages are to using > >>container-managed security I am not > >>able to fully deduce (except for the obvious -- > it's > >>nice to declare > >>stuff in web.xml in a standardized way -- and that > >>perhaps it might make > >>Servlets a *little* more portable if you wanted to > >>use them among > >>different apps). But then again, I haven't had to > >>take on a project yet > >>where the environment was extremely complicated, > >>when it came to how > >>users and permissions were managed (typically I > see > >>the same tried and > >>trusted setup -- USER, GROUP, ROLES and > PERMISSIONS > >>tables in some > >>central database, and some hand-rolled Java > >>component, used to authorize > >>the current request, that is invoked in some > >>"common" area, such as a > >>Servlet Filter -- or, in Struts, a base Action > class > >>or a custom > >>RequestProcessor). It seems like JAAS is still at > an > >>immature stage > >>perhaps, or at least the state of documenation > about > >>it is. > >> > >>The other route it seems you could go is to use a > >>container-managed > >>login as you suggest, and enjoy using the methods > >>such as > >>request.isUserInRole instead of invoking security > >>methods on a > >>hand-rolled component, but I think you will have > to > >>give up the > >>JBoss/Tomcat stack to do this for now (someone > >>please correct me if I am > >>wrong), because I think there is a security > >>integration problem there, > >>as I described earlier. I'm guessing Tomcat as > stand > >>alone might be a > >>good way to go though. I have not done this and > >>couldn't say whether it > >>is "common and usual". > >> > >>I have tried to write my role-checking methods so > >>that in the future if > >>I port an application to JAAS I can just refactor > >>them to invoke the > >>standard methods instead of my own. But like I > say, > >>I'm far from an > >>expert in this area. > >> > >>Hope that helps, > >> > >>Erik > >> > >>Leandro Melo wrote: > >> > >> > >> > >>>So Erik, is it a common and usual aproach to do > >>> > >>> > >>login > >> > >> > >>>outside of Struts (ordinary jsps), and then use > >>> > >>> > >>Struts > >> > >> > >>>afterwards??? > >>> > >>> > >>>--- Erik Weber <[EMAIL PROTECTED]> > >>> > >>> > >>escreveu: > >> > >> > >>> > >>> > >>> > >>> > >>>>Leandro, search the archives of this List for > >>>>"JAAS". I participated in > === message truncated === _______________________________________________________ Yahoo! Acesso Gr�tis - navegue de gra�a com conex�o de qualidade! http://br.acesso.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
