RE: case study with security
It is not necessary to create a specialty tag. If you are using container managed security and your users are set in specific roles you can use the logic:present tag with the role attribute. I do think the right way to do this is have the view conditional based on roles. Mike --- Marco Tedone <[EMAIL PROTECTED]> wrote: > I hope to give my 2 cents here. What I'm going to do (therefore > what I would > suggest you to do) is to create a custom tag like > which I'll use in my JSP to > present > the user some contents instead of some others. The background is > that I had > to create an application specific User authentication service, > based on XML > configuration file and commons-digester parsing to validate user's > login > information with the information contained in the XML configuration > file. > > The process looks like the following: > > 1) XML user's configuration file: -> XML file, containing user's > login info, > like username, password and role > 2) User Service -> A Business Service which, given the user's login > credentials, returns true if those match the XML configuration file > info, > otherwise returns false; > Login Action -> Uses the User Service and if user has the right > credentials, > CREATE a session attribute with the user details stating that user > has the > right credentials; > Tag library -> Retrieves session attribute for user(not the > container one, > but the application one, from the Form declared in session scope!); > if it > doesn't exists(meaning that user hasn't logged in succesfully) > returns > something like SKIP_BODY or EVAL_BODY. > > I had the need for that because I didn't want to bind, let's say, a > Tomcat > user with my application user. Now, thinking to put this custom tag > at the > beginning and at the end of what is crucial to your application it > could > work fine, in your case: > > > > > > > > > > > > Or something similar...I haven't implemented the model yet, so > these are > only ideas. > > Regards, > > Marco > > > -Original Message- > > From: Dan Allen [mailto:[EMAIL PROTECTED] > > Sent: Sunday, March 23, 2003 7:04 PM > > To: Struts-User List > > Subject: case study with security > > > > > > There have been several discussions on this list about how > > security should be loosely coupled with the ActionServlet > > itself (a filter on top of the application), but I am curious > > to know the best practicing for handling the following type of > case. > > > > Assume I have an action with a path of /EditAccount. > > Naturally if a user is not logged in, this path should be > > protected via filtering. However, /EditAccount has two > > purposes, one for the regular user to edit his/her own > > account, but also for the administrator to edit any user > > account via the query string ?user=username. In this case, I > > have to check in the action class if the user is allowed to > > take on the role of another user in which case the form is > > populated with that user's data or, if not, the form should > > populate with the user's own data. > > > > Is this something that is reasonable to do in the action, or > > should I create another action path > > /EditUserAccount?user=username and filter that to only admins > > and then forward to the /EditAccount once the proper > > credientials have been established, hence relieving the > > action behind /EditAccount from looking at any roles? > > > > Dan > > > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Daniel Allen, <[EMAIL PROTECTED]> > > http://www.mojavelinux.com/ > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > "If you are going to play the game of trial and error, > > don't be surprised when the results are revealing. -- me" > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: case study with security
I hope to give my 2 cents here. What I'm going to do (therefore what I would suggest you to do) is to create a custom tag like which I'll use in my JSP to present the user some contents instead of some others. The background is that I had to create an application specific User authentication service, based on XML configuration file and commons-digester parsing to validate user's login information with the information contained in the XML configuration file. The process looks like the following: 1) XML user's configuration file: -> XML file, containing user's login info, like username, password and role 2) User Service -> A Business Service which, given the user's login credentials, returns true if those match the XML configuration file info, otherwise returns false; Login Action -> Uses the User Service and if user has the right credentials, CREATE a session attribute with the user details stating that user has the right credentials; Tag library -> Retrieves session attribute for user(not the container one, but the application one, from the Form declared in session scope!); if it doesn't exists(meaning that user hasn't logged in succesfully) returns something like SKIP_BODY or EVAL_BODY. I had the need for that because I didn't want to bind, let's say, a Tomcat user with my application user. Now, thinking to put this custom tag at the beginning and at the end of what is crucial to your application it could work fine, in your case: Or something similar...I haven't implemented the model yet, so these are only ideas. Regards, Marco > -Original Message- > From: Dan Allen [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 23, 2003 7:04 PM > To: Struts-User List > Subject: case study with security > > > There have been several discussions on this list about how > security should be loosely coupled with the ActionServlet > itself (a filter on top of the application), but I am curious > to know the best practicing for handling the following type of case. > > Assume I have an action with a path of /EditAccount. > Naturally if a user is not logged in, this path should be > protected via filtering. However, /EditAccount has two > purposes, one for the regular user to edit his/her own > account, but also for the administrator to edit any user > account via the query string ?user=username. In this case, I > have to check in the action class if the user is allowed to > take on the role of another user in which case the form is > populated with that user's data or, if not, the form should > populate with the user's own data. > > Is this something that is reasonable to do in the action, or > should I create another action path > /EditUserAccount?user=username and filter that to only admins > and then forward to the /EditAccount once the proper > credientials have been established, hence relieving the > action behind /EditAccount from looking at any roles? > > Dan > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Daniel Allen, <[EMAIL PROTECTED]> > http://www.mojavelinux.com/ > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > "If you are going to play the game of trial and error, > don't be surprised when the results are revealing. -- me" > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
> Looks like a good solution to me. Excellent, I am starting to get this ;) > Note, btw, that I did not mean to recommend "desk phone" as a generic > identifier. Naturally, I will use what is specific to my app. Dan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Daniel Allen, <[EMAIL PROTECTED]> http://www.mojavelinux.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hey, somebody, sometime, somewhere, said something I think that just maybe might have been true but I think that I maybe didn't like it. F^CK IT, I'm suing everybody. -- slashdot member in response to petswarehouse.com sueing google.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
Dan Allen wrote: After reading the suggestions, I am going to go with two different actions for setting up the form. In order to use container managed security most effectively, I am going to prefix paths with admin restrictions with admin/ for ease of filter matching. So /EditAccount /admin/EditAccount?user=username Then I will make a common abstract Action class for editing an account which both actions will extend to make use of the common routines. The /EditAccount will not listen to any query params but rather use the current session data as the data to populate the form with, whereas the /admin/EditAccount will use the user parameter to lookup the user using the DeskPhone as suggested. This way, all the security is controlled by the container, but the logic is left in the action for simply setting it up as instructed (with no checks for security). Thanks for the input and append anywhere I have deviated from the suggestion. Dan Looks like a good solution to me. I agree that it is best to keep all of the security policies declaratively defined. I also like to keep the link between the logged in user and his/her account "automatic" (i.e., determined by the system and looked up as close as possible to the model updates) whenever possible. Your solution does both of these things. Note, btw, that I did not mean to recommend "desk phone" as a generic identifier. Obviously, a) the "lookup" key best for your admins to use depends on your application and b) whatever you use, it has to be unique. The app that I took the example from enforces this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
After reading the suggestions, I am going to go with two different actions for setting up the form. In order to use container managed security most effectively, I am going to prefix paths with admin restrictions with admin/ for ease of filter matching. So /EditAccount /admin/EditAccount?user=username Then I will make a common abstract Action class for editing an account which both actions will extend to make use of the common routines. The /EditAccount will not listen to any query params but rather use the current session data as the data to populate the form with, whereas the /admin/EditAccount will use the user parameter to lookup the user using the DeskPhone as suggested. This way, all the security is controlled by the container, but the logic is left in the action for simply setting it up as instructed (with no checks for security). Thanks for the input and append anywhere I have deviated from the suggestion. Dan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Daniel Allen, <[EMAIL PROTECTED]> http://www.mojavelinux.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "I am the GOD.the GOD...of house!" -- Leeloo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
Dan Allen wrote: There have been several discussions on this list about how security should be loosely coupled with the ActionServlet itself (a filter on top of the application), but I am curious to know the best practicing for handling the following type of case. Assume I have an action with a path of /EditAccount. Naturally if a user is not logged in, this path should be protected via filtering. However, /EditAccount has two purposes, one for the regular user to edit his/her own account, but also for the administrator to edit any user account via the query string ?user=username. In this case, I have to check in the action class if the user is allowed to take on the role of another user in which case the form is populated with that user's data or, if not, the form should populate with the user's own data. Is this something that is reasonable to do in the action, or should I create another action path /EditUserAccount?user=username and filter that to only admins and then forward to the /EditAccount once the proper credientials have been established, hence relieving the action behind /EditAccount from looking at any roles? Assuming that you are using container-managed security and roles, you can do it with one action by having the action ignore the user parameter unless the user is an administrator. You can check if the user is an administrator using if (request.isUserInRole("whatever-you-named-the-admin-role")). If the user is not an administrator, you can use request.getRemoteUser() to get the user id and then populate the form based on the user's own data. Here is a similar example: if ((frm.getDeskPhone() != null) && (request.isUserInRole(Constants.ADMINISTRATOR))) { rd.setDeskPhone(frm.getDeskPhone()); rd.retrieveByPhone(); } else { rd.setUid(request.getRemoteUser()); rd.retrieveByUid(); } ...use rd to populate current profile data onto frm... In this example, the "deskPhone" parameter is what the admin uses to loookup a user. The rd object is an entity-like bean that represents a user. If you decide to use separate Actions for admins and users -- eliminating the need for the conditional logic above -- you should make sure NOT to leave the user parameter in the queryString for the non-administrators or to add a check in the non-admin action to make sure that the user is editing his/her own profile. In this case, you should also encapsulate the common elements that both "editAccount" actions will share. Which approach is best depends on the complexity of the application and how you expect it to evolve over time. The second approach -- different actions for admins -- is more flexible but a little more work to implement. hth, Phil Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
A good practice is to use decelrative Container Managed Security. This kind of implies you set it up in web.xml (via a /securePath/*) or via action mapping in struts config. (writing you own security is not a good parctice, IMO) hth, V (do not cofuse that with the non container based filter implementation of above available from sf.net) Dan Allen wrote: There have been several discussions on this list about how security should be loosely coupled with the ActionServlet itself (a filter on top of the application), but I am curious to know the best practicing for handling the following type of case. Assume I have an action with a path of /EditAccount. Naturally if a user is not logged in, this path should be protected via filtering. However, /EditAccount has two purposes, one for the regular user to edit his/her own account, but also for the administrator to edit any user account via the query string ?user=username. In this case, I have to check in the action class if the user is allowed to take on the role of another user in which case the form is populated with that user's data or, if not, the form should populate with the user's own data. Is this something that is reasonable to do in the action, or should I create another action path /EditUserAccount?user=username and filter that to only admins and then forward to the /EditAccount once the proper credientials have been established, hence relieving the action behind /EditAccount from looking at any roles? Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
BTW,the current login user can only change his/her own login/acount profile -D - Original Message - From: "Dan Tran" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, March 23, 2003 11:16 AM Subject: Re: case study with security > In your case, you can make administrator is a 'user' itself so that > /EditAccount.do works for both roles. However, > I strongly suspect your action/view you have to do lots of if else block to > determine what to do and what to display. > > Encapsulation is the key here, I would provide 2 separate actions, one for > the normal current login user and one for administrator to edit any user > account. > > -Dan > > - Original Message - > From: "Dan Allen" <[EMAIL PROTECTED]> > To: "Struts-User List" <[EMAIL PROTECTED]> > Sent: Sunday, March 23, 2003 11:03 AM > Subject: case study with security > > > > There have been several discussions on this list about how security > > should be loosely coupled with the ActionServlet itself (a filter on > > top of the application), but I am curious to know the best > > practicing for handling the following type of case. > > > > Assume I have an action with a path of /EditAccount. Naturally if a > > user is not logged in, this path should be protected via filtering. > > However, /EditAccount has two purposes, one for the regular user to > > edit his/her own account, but also for the administrator to edit any > > user account via the query string ?user=username. In this case, I > > have to check in the action class if the user is allowed to take on > > the role of another user in which case the form is populated with > > that user's data or, if not, the form should populate with the > > user's own data. > > > > Is this something that is reasonable to do in the action, or should > > I create another action path /EditUserAccount?user=username and > > filter that to only admins and then forward to the /EditAccount once > > the proper credientials have been established, hence relieving the > > action behind /EditAccount from looking at any roles? > > > > Dan > > > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Daniel Allen, <[EMAIL PROTECTED]> > > http://www.mojavelinux.com/ > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > "If you are going to play the game of trial and error, > > don't be surprised when the results are revealing. -- me" > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > - > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
In your case, you can make administrator is a 'user' itself so that /EditAccount.do works for both roles. However, I strongly suspect your action/view you have to do lots of if else block to determine what to do and what to display. Encapsulation is the key here, I would provide 2 separate actions, one for the normal current login user and one for administrator to edit any user account. -Dan - Original Message - From: "Dan Allen" <[EMAIL PROTECTED]> To: "Struts-User List" <[EMAIL PROTECTED]> Sent: Sunday, March 23, 2003 11:03 AM Subject: case study with security > There have been several discussions on this list about how security > should be loosely coupled with the ActionServlet itself (a filter on > top of the application), but I am curious to know the best > practicing for handling the following type of case. > > Assume I have an action with a path of /EditAccount. Naturally if a > user is not logged in, this path should be protected via filtering. > However, /EditAccount has two purposes, one for the regular user to > edit his/her own account, but also for the administrator to edit any > user account via the query string ?user=username. In this case, I > have to check in the action class if the user is allowed to take on > the role of another user in which case the form is populated with > that user's data or, if not, the form should populate with the > user's own data. > > Is this something that is reasonable to do in the action, or should > I create another action path /EditUserAccount?user=username and > filter that to only admins and then forward to the /EditAccount once > the proper credientials have been established, hence relieving the > action behind /EditAccount from looking at any roles? > > Dan > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Daniel Allen, <[EMAIL PROTECTED]> > http://www.mojavelinux.com/ > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > "If you are going to play the game of trial and error, > don't be surprised when the results are revealing. -- me" > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - > 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]
case study with security
There have been several discussions on this list about how security should be loosely coupled with the ActionServlet itself (a filter on top of the application), but I am curious to know the best practicing for handling the following type of case. Assume I have an action with a path of /EditAccount. Naturally if a user is not logged in, this path should be protected via filtering. However, /EditAccount has two purposes, one for the regular user to edit his/her own account, but also for the administrator to edit any user account via the query string ?user=username. In this case, I have to check in the action class if the user is allowed to take on the role of another user in which case the form is populated with that user's data or, if not, the form should populate with the user's own data. Is this something that is reasonable to do in the action, or should I create another action path /EditUserAccount?user=username and filter that to only admins and then forward to the /EditAccount once the proper credientials have been established, hence relieving the action behind /EditAccount from looking at any roles? Dan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Daniel Allen, <[EMAIL PROTECTED]> http://www.mojavelinux.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "If you are going to play the game of trial and error, don't be surprised when the results are revealing. -- me" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]