Michael, I am glad you got it working.
> > I am not sure how much value the roles attribute for an > > action has if it can't invoke the authentication sequence > > (i.e. send you to the login page, and get you back to your > > original request). It seems you would have to duplicate the > > I assumed Struts would in fact do this. If it doesn't then I don't see > how this feature can even be useful. I definitely don't want my user to > get an error message when they try to access the site. Can someone > confirm if Struts can provide this functionality (sending the user to a > login page and then returning them to the original action requested)? I think Struts might be able to do something tricky, but it probably isn't worth the headache. I can imagine a sequence like this: Scenario #1: not authorized 1. Request for action comes in, but the authenticated user does not meet the role requirement. 2. Struts sets the 403 error code and returns, letting the container show the 403 error page. (it might do this already, but it seems weird that you got a 400 error page that said "not authorized", so I am not sure) Scenario #2: not authenticated 1. Request for action comes in, but the user is not authenticated. 2. Struts remembers the action requested and redirects to a special secured URL. 3. The container sees that you aren't authenticated to access the special secured URL and sends you to the login form. 4. You sumbit a login form, and get redirected to the special secured URL. 5. The response from the special secured URL is a redirect to the action you originally requested. 6. Your request for the original action succeeds now that you are authenticated and meet the role requirement. The only problem here is keeping the POSTed parameters, if the original request was a POST. This either requires special handling in Struts (to make them available to the Action, but not any non-Actions you might forward to, like a JSP) or a filter to make the posted parameters available to all resources in the request. Perhaps there is an opportunity for synergy between Struts and the SecurityFilter project here. > > > Also, watch out for specifying http-methods in web.xml, as > > the settings won't match if the request is using a different > > method. This might be okay if you want to ONLY allow GETs and > > POSTs and block access to everything else with another > > You lost me. What else is there besides GET & POST? We're doing a > basic webapp, HTML browser based. Those are the two most important/common ones, but there are a bunch more (OPTIONS, HEAD, PUT, DELETE, TRACE, CONNECT). Your actions will only respond to GET and POST (is this right, listers?), so this probably isn't a major issue. I suggest not specifying the http-method for your circumstances (so the security-constraint will match all requests for the patterns, regardless of the method), but like I said it probably isn't a major concern either way. I wouldn't worry about it, but you might benefit from the opportunity to reduce the bulk of your web.xml file. -Max -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
