Scott Purcell wrote:
Thank you very much for your comments on this topic Paul.
Now, I understand the basics of using a filter, extending the base class and configuration in the web.xml file. But how can I use a filter in unison with Struts.
I am not seeing how I would use the filter. Are you implying that I should possibly use the filter to check for the existance of the session and "user" object? And if the session does not exist? use a redirect to the login page? So this filter would only look at incoming requests?
You might want to check out some docs on the servlet specs etc.
Sessions exist once the user begins interacting with the servlet container (in general). What other kinds of requests are there other than incoming requests?
Filters, in the case of Struts, sit between the user request and Struts processing (they are invoked, in the order defined in the web.xml file, before any servlets).
Whether or not it's advisable to put user auth. in a filter or a RequestProcessor is probably debatable: I ended up ensuring users were in session using a filter but doing the auth. in a RequestProcessor--the big win doing it this way is that you can set up access roles in the Struts configuration file. If you do your auth in a filter you could not do this unless you read in the Struts config file, which would mean it's being parsed twice, and I don't see any compelling reason to do that.
That said, if you have anything on your site that is _not_ under Struts control (for instance, static HTML pages) doing auth in the RequestProcessor won't work, as the Struts components won't be called in those cases.
So, in my filter I check for the existence of a user session object:
public void doFilter(...params...) throws IOException, ServletException {
HttpSession session = ((HttpServletRequest) request_).getSession();
User user = (User) session.getAttribute(AttributeKeys.SESSION_USER_KEY);
if (user == null) {
//...get guest user id from db session.setAttribute(AttributeKeys.SESSION_USER_KEY, guestUser);
}
filterChain_.doFilter(request_, response_);
}
Since the filter is executed on EVERY request, barring heinous circumstances, I am guaranteed to have a user object in session scope every time I enter the Struts processing chain.
Now, you could do auth inside this same method: once you have a user in session just do whatever auth processing you need to do. If auth is successful, continue. If not, go to a loginn URL, which could be anything: a JSP, a servlet, an action, whatever. You can set up a filter init-param in the web.xml so you don't have to touch code to change the URL.
However, if you want to keep the permissions inside the struts config, which I personally do, this might not be the way to go about it. Instead I use a RequestProcessor, which already knows about the struts config file and the roles defined for each action (if any). Inside the processRoles method of my RequestProcessor I can compare an action's roles against the user name and everything is ducky.
I could put the filter code inside the request processor just as easily if everything was Struts-y; I already have the filter as a drop-in component so I didn't see any good reason to do that at this point. It might make more sense, though.
Seriously, there are a wealth of Really Good Resources on the web for most of these questions, and I'd encourage you to check them out--you'll probably save yourself some time waiting for list responses.
Dave
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
