This is a question that's only partially related to Struts, but on the topic of application security. The crux of it is trying to understand how to faithfully redirect a request, including the HTTP method. For a number of reasons, we've chosen to implement a lightweight authentication and authorization framework for our application that hangs off of ActionServlet (in short, we needed something in place until a higher-level decision on 3rd-party access control could be made by others outside our group.) We check on each request that we have a user logged in (by the presence of a user object in the session), and then that they have permission to request the given resource. Our definition of "resource" is a combination of HTTP method (GET, POST) and URL, similar to what the servlet 2.2 spec defines. The general flow is to (a) check whether the user is authenticated (b) if not, we save the URI they requested and forward them to our logon page (c) after logon, we check their credentials, and if they pass we redirect to the saved URI. The problem we're having is that it appears that the redirect done in (c) is always turned into a GET request, even if the original request was a POST. If we have a valid permission for the original POST request, we may well not have one defined for the GET method, and we'll get an authorization failure. Now, I've come to realize that this may just be an academic question, since on a POST, we will have lost our form data from the original request by the time the user has gone to a logon page and submitted that (unless we go to more extraordinary measures to save it), so that I'm starting to believe that our safer strategy in (c) is to simply redirect to our home page after authentication, in all circumstances, since everyone has rights to that URL via GET or POST. However, it's been gnawing at me that others have had to deal with something like this, but I don't know how. I've tried looking through the Tomcat 3.2.1 source to understand how it does form-based logon, and I'm still stymied. I can see where the AccessIntercepter stores the URI before a logon attempt, and then sends it back with a 302 response after logon, but that technique would also seem to lose the original HTTP method, and fail the same way in this situation (although I haven't taken the time to setup a secured Tomcat webapp to test the theory.) I've even gone so far as to check out the HTTP 1.1 spec to understand the "redirect" directive, but even that doesn't come right out and say "the HTTP method is lost (or preserved) on redirect." The closest thing of interest is a note in section 10.3.3, describing the 302 (temporarily moved) request: "Note: When automatically redirecting a POST request after receiving a 302 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request." So perhaps its a browser bug, but we're using IE 5, which I would hope would be a little more current. Thanks for any clues, insights, or tales of similar woe. John
