struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijay Balakrishnan <>
Subject [OT] RE: Webapp Security?
Date Thu, 03 Jul 2003 18:04:51 GMT


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

Thanks in advance,

-----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.


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

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

View raw message