struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [OT] RE: Webapp Security?
Date Thu, 03 Jul 2003 18:17:55 GMT

On Thu, 3 Jul 2003, Vijay Balakrishnan wrote:

> Date: Thu, 3 Jul 2003 11:04:51 -0700
> From: Vijay Balakrishnan <>
> Reply-To: Struts Users Mailing List <>
> To: 'Struts Users Mailing List' <>
> Subject: [OT] RE: Webapp Security?
> HI,
> On a similar vein, I am running into a problem with web security and thought
> I will bounce it off all the gurus here in this forum.
> I am trying to do FORM based authentication and am using login.jsp with an
> action of j_security_check with SunOne App Server.
> The j_security_check seems to be redirecting(302) the output from login.jsp
> after authenticating.I need to collect the j_username and
> j_password from the request in my index.jsp.I tried using a Filter on
> /login.jsp and /index.jsp to change the status code from 302 to 200 but that
> did not work.I can't seem to put j_security_check in the web.xml as a
> servlet name or url pattern in the filter.How would I access
> the j_security_check ?
> I have used a simple login.jsp but my client wants to use Form based
> authentication.

When you are using form-based login, it is not appropriate to consider the
login page itself to be part of your application -- instead, think of it
as part of the container, reserved solely for the container's use.  To get
a feel for how this works dynamically, temporarily change your app to use
BASIC authentication instead.  See?  There is no such thing as a login
page, because it is a built in feature, and that is the way you should
think of the login page for form-based login as well.

When using form-based authentication, the login page is used (by the
container) when an unauthenticated user tries to access a protected
resource for the first time.  The container saves the original request,
and (after successful authentication), the redirect done by the container
is to "replay" that original request.  Again, the design goal of the whole
process is to simulate the user experience of BASIC authentication (in
that case, the browser is the one that replays the transaction, but it
feels the same to the user).  Trying to do something directly with the
login page, then, is misusing this functionality.  Even if you find a
hack that works for one container, you can be pretty sure it won't be
portable to anywhere else.

After successful login, the username will be visible to your application
by calling request.getRemoteUser().  You can programmatically check
whether the authenticated user has a particular role, by calling
request.isUserInRole().  The password is not visible, and IMHO that is
exactly the way it should be -- using container managed security means
that the application keeps its hands off of sensitive information like

> Thanks in advance,
> Vijay


> -----Original Message-----
> From: Craig R. McClanahan []
> Sent: Thursday, July 03, 2003 10:35 AM
> To: Struts Users Mailing List
> Subject: Re: Webapp Security?
> On Thu, 3 Jul 2003, Adam Hardy wrote:
> > Date: Thu, 03 Jul 2003 13:47:20 +0200
> > From: Adam Hardy <>
> > Reply-To: Struts Users Mailing List <>
> > To: Struts Users Mailing List <>
> > Subject: Re: Webapp Security?
> >
> > Adam Hardy wrote:
> > > Marc wrote:
> > >
> > >> To protect your JSP, put them in a subdir of WEB-INF. Actions are
> > >> still able to redirect to those JSPs but they are not direct
> > >> accessible.
> > >>
> > >> To protect your other files, just make a servlet and use
> > >> path-mapping like '/resources/*' to map all requests to this
> > >> servlet.
> > >
> > >
> > >
> > > What kind of security breaches are JSPs susceptible to, once they
> > > protected by a security-constraint path mapping?
> >
> > what I mean is, are other files like HTML & style sheets & images
> > vulnerable?
> The reason people are concerned about putting JSP pages inside /WEB-INF is
> generally to avoid clients trying to access them directly (by typing a URL
> into the location bar); it is not really a security issue.  In effect, the
> container provides an automatic security constraint that disallows ALL
> direct accesses from the client to anything under /WEB-INF.
> What you generally care about (from a security perspective) is ensuring that
> only authorized persons can perform dynamic actions on your web application.
> If you don't care who can do something, then don't protect it with a
> security constraint.  The same goes for static content -- if the content is
> confidential to people that only have a particular role, then protect it
> with a security constraint that requires that role before allowing access.
> It doesn't matter whether the particular resource is implemented with JSP
> pages or ASP, or whether it's static or dynamic -- the key question is
> "should person X be able to access it".
> It is *generally* simpler to use container managed security for things like
> this, because you can declare the constraints declaratively in your web.xml
> file, and not have to enforce it with functional logic inside your app.  But
> there are also going to be cases where your needs go beyond what standard
> container managed security provides -- the way you make a choice should
> start from understanding what you're trying to protect and from whom, before
> deciding how to protect it.
> Craig
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message