Hi, I checked out SecurityFilter yesterday, after Robert Taylors recommendation, and have looked through a good bit of the source. I'm probably going to use your package once i get this thing closer to its final state. It looks like a great program.
I like to write my own "lite" versions of packages i use, if possible, just to feel that i really know whats going on. I even did this with struts, believe it or not. I wrote a struts lite that uses a controller, action forms and actions, and an xml config file. I used it for a couple of small projects, and now that i've got a handle on the basic idea, i feel i can use the real Struts with more confidence. Right now concentrating on becoming very familier with Struts, once i get that down, in a couple of weeks i'll pop your Security Filter in. dave On Fri, 2004-02-27 at 01:31, Max Cooper wrote: > I'm the primary author of the SecurityFilter project, and the filter > logic is a bit more complicated than the code that was posted. Even if > you decide not to use SecurityFilter, it is probably worth a look at the > doFilter() method. > > Some issues that you will/may have to deal with: > 1. Filter getting executed on forwards (depends on your container). > 2. Sending the user back to the page they requested when the login > sequence was initiated (a key feature, IMO). > 3. Keeping request parameters (both GET and POST) across the login > event. > 4. Sending the user to an error page when the login fails. > 5. Allowing login form and error page requests to be processed without > invoking the login sequence. > 6. Knowing what to do / where to send the user if they authenticate > spontaneously (i.e. when they weren't sent to the login form by your > filter). > > Basically, there's a lot of stuff to deal with even though it seems > simple at first. :-) If you can use container-managed security or > SecurityFilter, you'll probably save yourself some time that would > otherwise be spent dealing with these issues. It is worth investigating > the existing solutions before rolling your own. > > -Max > > On Thu, 2004-02-26 at 09:20, Robert Taylor wrote: > > You may want to see if this supports your requirements: > > > > https://sourceforge.net/projects/securityfilter/ > > > > > > robert > > > > > > > -----Original Message----- > > > From: David Evans [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, February 26, 2004 12:07 PM > > > To: Struts Users Mailing List > > > Subject: servlet filters and authentication > > > > > > > > > Hello, > > > > > > I'm configuring the skeleton of a multi module struts application, and i > > > would like use a filter for the authentication. > > > > > > here is psuedojava (for easier reading) of the filter: > > > > > > public final class AuthFilter implements Filter { > > > > > > public void doFilter(request, response, chain) > > > > > > session = request.getSession(); > > > auth = session.getAttribute("authenticated"); > > > if (auth == true) { > > > chain.doFilter(request, response); > > > return; > > > } > > > else { > > > dispatcher = > > > request.getRequestDispatcher("/WEB-INF/jsp/security/login.jsp"); > > > dispatcher.forward (request, response); > > > return; > > > } > > > } > > > } > > > > > > > > > I've seen this skeleton suggested in several places on the web. > > > The question i have is this: After the user submits the login form, > > > the request will come through the filter, and since it has not yet > > > been authenticated, it will again forward to the login.jsp. > > > I've thought of a couple of ways to deal with this and > > > would like to get input on these and any other approaches. > > > > > > 1) set the mapping of the filter in web.xml in such a way that it > > > allows the login action through. maybe set all actions to have an > > > extension of .do except the login action, which has an extension of > > > .auth. I don't think this will work for me, because the multi module > > > support of Struts requires extension mapping. I guess i could write a > > > small serlvet that is not in the struts mapping but is in the same context > > > and have it mapped to *.auth > > > > > > 2) check within the above filter to see if the request is for the login > > > action, and if so allow it through. so the if statement above would be: > > > if (auth == true || req.getPath().equals("login.do")) > > > > > > Any comments on these ideas or approaches i haven't listed would be > > > greatly appreciated. > > > > > > 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] > > > > > --------------------------------------------------------------------- > 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]
