struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <>
Subject RE: Authentication and Authoirzation
Date Wed, 04 Oct 2000 23:07:26 GMT
> -----Original Message-----
> From: Craig R. McClanahan []
> Sent: October 4, 2000 6:32 PM
> To:
> Subject: Re: Authentication and Authoirzation
> > > 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.
> >
> Ah, I see what you are getting at now.  Since what you've got 
> works I would
> suggest not changing it, but here is a way to use declarative 
> security with
> extension mapping in a convenient way.
> The key insight is that extension mapping works on the last 
> "component" of a
> request URI.  So, if you map your action servlet to the 
> "*.do" extension in the
> usual way, ALL of the following URLs map to it:
>     http://localhost:8080/myapp/
>     http://localhost:8080/myapp/admin/
>     http://localhost:8080/myapp/very/long/prefix/path/
> so, if you organize your action mappings by sharing a common 
> prefix around the
> things you want to protect with the same security constraint, 
> you can have the
> same convenience that you do with path-based mapping.  For 
> example, lets say you
> have a set of administrative actions that are part of your 
> Struts app.  If you
> create action mappings for paths like this:
>     /admin/option1
>     /admin/option2
>     /admin/option3
> then you can have a security constraint on pattern "/admin/*" 
> and protect them
> all with one constraint, even though you are using extension 
> mapping to map to
> the controller servlet (i.e. the first option above would be 
> requested at
> "http://localhost:8080/myapp/admin/").

Absolutely, this is exactly what my first approach did, came in as
and then as a variation I went to
but whether you come in via an extension or a path prefix, in either case
you stil have the fundamental problem that you are coming in off a non-base
path from your context, so your JSPs are hosed for relative paths (without
the <base> tag trick). The only way is to come in with an empty base path:

> A different approach is that you would also have the choice 
> of protecting each
> individual action mapping path ("/") with its 
> own security
> constraint.  This is not very practical if you have a large 
> application, but
> might work fine if you have only a few.

Hmm, this would actually probably work quite well or quite badly depending
on how the servlet engine did its matching. If it used some sort of hash to
map exact patterns then it would not be a big deal if you did have 100 or
200 different authorization constraints like
This is essentially what I am doing now anyways, at another level, in that I
have the whole bunch of extra action mappings defined just so I can do the
security contraints.

It's just a lot of work to keep track of for the deployer, either way. I
_really_ _really_ want to be able to map security constraints with wildcards
for some subactions, one way or another, whether I do it using the Servlet
2.2 mechanism, or my current solution.

View raw message