Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
Message-ID: <2D90C2075E27D4118960000629A832E5CE93E0@scooby.corp.bspark.com>
From: Colin Sampaleanu <colin@Bspark.com>
To: "'struts-user@jakarta.apache.org'" <struts-user@jakarta.apache.org>
Subject: RE: Authentication and Authoirzation
Date: Wed, 4 Oct 2000 18:14:28 -0400 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: October 4, 2000 4:16 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Authentication and Authoirzation
> 
> See intermixed.
> 
> Colin Sampaleanu wrote:
> 
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> > > Sent: October 4, 2000 2:26 PM
> > > To: struts-user@jakarta.apache.org
> > > Subject: Re: Authentication and Authoirzation
> > >
> > > Melroy Rodrigues wrote:
> > >
> > > > Hi,
> > > >
> > > > Does anyone know if I will be able to use the
> > > > RDBMSRealm for authentication and then the ACls
> > > > in web.xml for authorization with Struts?
> > > >
> > > > Thanks
> > > > Melroy
> > >
> > > You can certainly use the container-managed security 
> features of the
> > > Servlet 2.2 specification in a Struts application.  The
> > > reason I did not
> > > do so in the example is that, unfortunately, how you tell
> > > your container
> > > where to find the list of users and their roles is 
> specific to each
> > > container (not portable).  For example, Tomcat lets you 
> configure an
> > > appropriate Realm implementation -- other containers do it
> > > differently.
> > >
> > > Struts, on the other hand, does not care how authentication
> > > is done, and
> > > it doesn't enforce the authentication and access control 
> rules because
> > > the container does it for you.
> >
> > There is a fundamental problem in using the declarative (path-based)
> > security feature of Servlet 2.2 containers, in an 
> environment running both
> > Servlets and JSPs. This is the approach we tried initially, 
> but we gave it
> > up for another way... The problem is that when your 
> servlets redirect to
> > JSPs the browser doesn't know anything about it, and 
> assumes all relative
> > resource references (hrefs, etc.), are off the original path.
> 
> That is true, but it's also a problem whether or not you are 
> using declarative
> security, right?

Absolutely, but my whole point was that the only way to use declarative
security (in a standard fashion) is to come in via different paths (not
extension mapping), and this breaks JSP relative links, so you have to pick
one or the other. Since I need to be able to use relative links in the JSPs,
this basically killed declarative security, using the standard Servlet 2.2+
mechanism. Luckilly I figured out the other way to do 'declarative
security', as per my original message.

> Here are two approaches to dealing with it:
> 
> * Use extension mapping (like the example app does) and no 
> subdirectories
>   in the document root.  That way, the relative references 
> still work correctly
>   because the browser thinks that the actions and the pages 
> are all at the
>   same "directory level".

As per above, coming in via an extension doesn't allow declarative
security...

> * Use the (fairly new) <struts:base/> tag somewhere in the 
> <head> section
>   of your JSP page.  This generates something like this:
> 
>     <base href="{URL-of-the-JSP-page}">
> 
>   so that relative references work no matter what URL was used to call
>   the action (i.e. the URL that is still showing in the 
> browser window).

Hmm, I think this would work fine except in the case that you want to
redirect to a simple HTML file. If you are ok with always calling JSPs then
there are no big disadvantages. At this point though we do have the other
system working with no restrictions, so will probably stick to it.