You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Nacho <na...@siapi.es> on 2000/06/14 15:56:31 UTC

About security

Hi, All

I'm little confused about the struts security and Tomcat security, in
the app we are developing, all the security is used trought tomcat, that
is using request.getRemoteUser and so on and let tomcat do the
authentication.

Why this is not the way that struts work?

Saludos ,
Ignacio J. Ortega


Re: Struts and Orion App Server

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Kevin Duffey wrote:

>
> Second, Struts defaults to /WEB-INF/action.xml to load the action.xml config
> file. Apparently, this is not allowed per Servlet 2.2 spec..an app can not
> access the WEB-INF dir, only the server can. I don't know how valid this is,
> but as soon as I moved action.xml to my /www folder, and in my
> WEB-INF/web.xml file set the init attribute of config to use /action.xml
> (instead of /WEB-INF/action.xml) everything worked.
>

It is perfectly acceptable for a servlet or JSP page to use the
ServletContext.getResource() call to access things in the WEB-INF subdirectory.
If your servlet container does not let you do this, it's a bug in the
container.  (The reason this directory was defined as it is in the servlet spec
was for precisely this purpose -- to hold configuration files and other things
in a well-defined place.)

What is prohibited is serving the contents of any file under WEB-INF in response
to a client request like this:

    http://www.mycompany.com/WEB-INF/action.xml

because you don't want clients to be able to snoop your configuration files.
After all, there is often sensitive information like database passwords stored
in these files.

Craig



Struts and Orion App Server

Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,

Just wanted to inform anyone using Orion what seems to be happening. After
talking with Craig and the Orion team and users, a few things have been
noted.

First, there is a bug in JDK1.3 with getResource() calls, which Struts uses
to load locale information. So, if you use JDK 1.3 to run Orion (and I would
assume the same problem exists for Tomcat and other engines), you will
consistently be getting a "can't load resource" error in the browser. At
least that is what happens to me.

Second, Struts defaults to /WEB-INF/action.xml to load the action.xml config
file. Apparently, this is not allowed per Servlet 2.2 spec..an app can not
access the WEB-INF dir, only the server can. I don't know how valid this is,
but as soon as I moved action.xml to my /www folder, and in my
WEB-INF/web.xml file set the init attribute of config to use /action.xml
(instead of /WEB-INF/action.xml) everything worked.

On that note..Craig, it is now working. As long as I use JDK 1.2.2, and put
action.xml in /www, it seems to work. I sent a form to an action, and it is
indeed getting the request.

Now, I assume we wait for a JDK1.3.1 patch or something and hope they fix
this problem. As for the /WEB-INF access, I am not sure why this happens.
Craig, maybe you can look into this and see why Tomcat allows this but Orion
doesn't. Without starting a war between the two products, supposedly Tomcat
is not in full compliance if it allows WEB-INF access from a deployed
application..this has been not allowed because of security issues. I'd love
to hear about this.

Thanks.


Re: About security

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Nacho wrote:

> Hi, All
>
> I'm little confused about the struts security and Tomcat security, in
> the app we are developing, all the security is used trought tomcat, that
> is using request.getRemoteUser and so on and let tomcat do the
> authentication.

>
> Why this is not the way that struts work?
>

I assume you are talking about the example application that comes with
Struts?  I would prefer to use container-managed security as well -- but in
this particular scenario the application "requirement" was that new users
could register themselves -- much like you can on many portal sites -- and
that the new user identity would become immediately available.

Currently, there is no portable (across servlet containers) way to let my
application update the same "user database" that is being accessed by the
servlet container for authentication.  I could have made the example
Tomcat-specific, for instance, but that did not seem like the right thing to
do.  Therefore, I implemented application-managed security in the example
application.


>
> Saludos ,
> Ignacio J. Ortega

Craig