Hi, there is one gotcha here, interceptor or action based authorization is for actions and not for resources files. So if one want's to protect access to some kind of *.pdf files on server disk one can set pdf as action extension in struts.properties and create an action that will check if logged in user has right to download this file and return stream of requested file contents. There is also a possibility to include parameter names after action name like /namespace/action/1/2/3/mySecret.pdf so that action can locate mySecret.pdf with help of these parameters if that's necessary.
If there is a simpler way of acheving this some please advice, i've just implemented such a scenario for my customer and it would be very nice to make it simpler. Best greetings, Paweł Wielgus. 2010/8/10 Guy Thomas <guy.tho...@vlaamsbrabant.be>: > I was thinking of using declarative security (in web.xml) for resource > authorization. Is this a good idea? Is it enough? > > -----Oorspronkelijk bericht----- > Van: CRANFORD, CHRIS [mailto:chris.cranf...@setech.com] > Verzonden: maandag 9 augustus 2010 15:50 > Aan: Struts Users Mailing List > Onderwerp: RE: URL authentication > > Pattern A: > > /unsecured/* > > Run whatever unsecured interceptors on these. This would not include the > authentication interceptor or the allowed resource check interceptor. That's > because these are considered OPEN to everyone. > > Pattern B: > > /secured/* > > Run the authentication check and the resource check interceptors. > > The authentication check would verify simply that the HttpSession object > contains whatever credential token in memory. If this value doesn't exist, > you simply don't have any authentication, return LOGIN as your result, > sending the user to the login page. The neat thing we did when this happened > in our application is we captured the original resource and any parameters, > set that value to a page scope variable and stored it in the login form. > This way when the user called the LoginAction, we could redirect the user to > the original requestsed resource once we got their credentials. > > The resource check logic for us in my case was simple as well. When we grab > the authentication object (User object that is), the object gets populated > with a map of resources and their access permissions. This way the data is > grabbed only once and gets stored in the session object only during login. > Therefore, all resource checks simply verify that the user object contains > the resource and desired access. There is no trip to the RDBMS on each web > call, reducing the overhead. If a user's access changes during a session, it > doesn't get updated. They simply logout and back in and the access is fixed. > > Lots of ways to do it, but I would keep them separate. > > Chris > >> -----Original Message----- >> From: Dave Newton [mailto:davelnew...@gmail.com] >> Sent: Monday, August 09, 2010 6:23 AM >> To: Struts Users Mailing List >> Subject: Re: URL authentication >> >> FWIW, I wouldn't combine the two into the same interceptor since >> rather different things... plus resource access is more likely to take >> in a different layer, and not be a cross-cutting concern. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > > > > ------------- > Aan dit bericht kunnen geen rechten worden ontleend. Alle berichten naar dit > professioneel e-mailadres kunnen door de werkgever gelezen worden. > Ondernemingsnummer: 0253.973.219 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
