Re: Alternatives to J2EE Authentication
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]
Alternatives to J2EE Authentication
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. -- Steven J. Owens [EMAIL PROTECTED] I'm going to make broad, sweeping generalizations and strong, declarative statements, because otherwise I'll be here all night and this document will be four times longer and much less fun to read. Take it all with a grain of salt. - Me at http://darksleep.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternatives to J2EE Authentication
http://securityfilter.sourceforge.net/ This is perfect! Not container specific! On Feb 26, 2004, at 4:19 PM, 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. -- Steven J. Owens [EMAIL PROTECTED] I'm going to make broad, sweeping generalizations and strong, declarative statements, because otherwise I'll be here all night and this document will be four times longer and much less fun to read. Take it all with a grain of salt. - Me at http://darksleep.com - 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]
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]
