Here we have application using struts and giving priviledges to some users or some roles. We rely on container security to handle login. We simply put a link to /jsp/admin which redirects to the / and, in web.xml, we ask for everything under /jsp/admin to require authentification. This way request.getUserPrincipal() does now and for as long as session goes contains the authentified user. This has the advantage of being easy to put in place. I like to think 'As long as the container can do the job for you, let the container do it, it's faster to code' :)
Regards, -- David Delbecq Royal Meteorological Institute of Belgium Le Lundi 25 Avril 2005 20:21, Dave Newton a écrit : > Scott Purcell wrote: > >I am creating a shopping-cart type application using struts and have a > > question. The site itself does not have any authentication on it, as > > people just browse and add stuff to the cart. > > > >But the site does require some data manipulation into the database. Upon > > thinking about this, I would like to be able to have "certain" users > > click a administration link and be able to administer some product > > details, quantities, colors, etc. > > > >I am trying to lay out a way to achieve this, and be secure at the same > > time. I had thought about using the web-server authentication mechanism, > > or form-based, and got confused. Most sites I have done use form-based, > > where we pull out name, password from database, but I also believe some > > may use the containers authentication scheme. > > > >Can anyone give me some advice, pros-cons, examples, links of how to move > > foward with this. > > There were a few recent threads about the pros and cons of writing a > custom request processor vs. filters vs. a combination of the two vs. > container-managed etc; the archive might be of high value. > > My own take on it is that if everything is done in Struts I like the > custom request processor coupled with a filter to make sure the > appropriate objects are always in session, but I already had fairly > general-purpose filters in place. > > If not everything on the site is in Struts then a filter approach might > work better, if it's all Struts then you could (should?) do it all in a > request processor: this allows very easy declarative role-based security > in the struts config file. One possible caveat is that the struts tags > that take role parameters do not know anything about a custom role > processor (is that still true???) so if you want role-based > content-level decision making you might need to write your own tags, > customize existing tags, etc. > > But check out the recent threads to get more input. > > Dave > > > > > --------------------------------------------------------------------- > 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]
