Hello.
The idea of a servlet filter to manage part of the user login process
that I read here rang a bell in my head. Diggin' in books & articles I
finally found where I have first heard such a thing :^) In "Professional
Struts Applications" (Carnel, Linwood, Zawadzki - Apress, 2003) the authors
state that it is possible to define "[...] a filter [...] that checks if the
user is logged on into the application. If the user has not logged in yet,
they will automatically be logged in as an anonymous user", furthermore,
"[...] this filter is called every time the Struts ActionServlet is invoked"
(achieved by mapping the filter and action servlet to the same url pattern,
of course)
This whole filter thing seems like a pretty good trick to me, and
becomes even more interesting if, for instance, you think of adding Tiles
into the mix to take care of different (and automatically loaded)
application Look & Feel depending on the type of user...
Anyway, just some thoughts I thought I'd share on the list...
Best regards,
Carlos
"You start coding. I'll go find out what they want."
Computer analyst to programmer
----- Original Message -----
From: "David Evans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 26, 2004 10:31 PM
Subject: Re: Alternatives to J2EE Authentication
> Having just researched this, here's what i found.
> Using a javax.servlet.Filter works very well.
> As you say, You check the session for an attribute value that indicates
> authentication. in its absence you use a RequestDispatcher to
> forward to a login servlet which checks for four cases:
> 1. no request parameters, display logon form
> 2. invalid request parameters, display errors
> 3. unable to authenticate with valid parameters, display error
> 4. parameters authenticate, forward to home page
> Thanks to Rick Bay on the struts-users list for this idea.
> along with option 3 on this email.
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg24504.html
>
> This is a fully featured, xml file configurable filter
> that i will eventually use as my solution:
> http://securityfilter.sourceforge.net/
>
> but for fun and understanding i wrote (cut and pasted bits from the web
> really) this one, as a test:
>
> public final class AuthFilter implements Filter {
>
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain)
> throws IOException, ServletException {
>
> boolean auth = false;
>
> if (request instanceof HttpServletRequest) {
> HttpSession session =
> ((HttpServletRequest)request).getSession();
> String path = ((HttpServletRequest) request).getPathInfo();
> Boolean authAttr =
> (Boolean) session.getAttribute("authenticated");
> if (authAttr != null) auth = authAttr.booleanValue();
> }
> if (auth) {
> chain.doFilter(request, response);
> return;
> }
> else {
> RequestDispatcher dispatcher =
> request.getRequestDispatcher("/login.do");
> dispatcher.forward (request, response);
> return;
> }
> }
>
> }
>
> Hope that helps.
>
> dave
>
> On Thu, 2004-02-26 at 18:19, Steven J. Owens wrote:
> > Hi folks,
> >
> > The most common (and frustrating) bookmarked login page gotcha
> > with J2EE authentication has been oft-discussed (broken as designed)
> > on this list.
> >
> > What are people's favorite alternatives to J2EE authentication?
> > And why?
> >
> > Something I'm particularly interested is alternatives that don't
> > require me to rebuild the application from scratch. I'm looking at
> > tearing out the old login process and putting in a new one and I don't
> > really want to start the whole thing over.
> >
> > If I had to build it from scratch myself, I'd do it as a simple
> > Servlet filter that checks for a Principal object stored in the user's
> > HttpSession.
>
>
> ---------------------------------------------------------------------
> 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]
