> I think there are two major reasons why Rickard wants
> to discard URL with .action.
>
> 1. to get declarative security working
>
[snip]
>
> IMO, only #1 is reaonable. Still, lots of us already
> implement authentitation filter to get around the
> prob. with the path. That's not to say that we need
> not to fix that, but IMO there should be better way
> then getting rid of .action URL.
As a recent struts to WebWork convert, I was surprised to find that
http://somesite.com/path/bar.action
was exactly the same as
http://somesite.com/path/foo/bar.action
to webwork. While I've seen a couple posting asking this same question,
I haven't seen an answer. I agree with Hai and a number of the other
posters that this goes a long way to fixing the security issue.
I look at it this way. There are a couple accepted ways of implementing
declarative security:
1. Securing based on path (Servlets for example)
2. Securing based on authenticated role (EJBs for example)
There are of course proprietary implementations. Ideally, I would love
XWork to support 1 and 2 orthogonally. I can understand forcing
developers to rely on approach 1 as it's a common web practice, but I
can't agree with forcing developers to use approach 2 only.
Production environments may combine a variety of different technologies.
If a company already has a system that utilizes path based security (1),
they shouldn't be forced to declare security in two places. Likewise,
if EJB style security is already being used, it'd be nice to have the
option of using that with their XWork actions.
Note - I'm not proposing that we using EJB style security declarations,
I'm just using it as an example of tying security to the action
performed rather than the path requested.
--
Matt Ho
Principal
Indigo Egg, Inc.
http://www.indigoegg.com/
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
