Jason Carreira wrote:
As opposed to the extra configuration to assign roles to packages and
coordinate them with the roles in web.xml? I really don't like the
idea of putting security information into xwork. If we pinned
packages to URL paths, and protected the paths using J2EE declarative
security, you've only got security information in one place, and it
can be changed at deploy time (and even at run time, depending on
your servlet container).
Good point. I agree with that. But, there's still a need to add roles to xwork.xml I think, for the cases where the actions are invoked by other actions, or by some dispatcher other then a servlet controller.

No, but the controller servlet can, I think. If the execution interceptor returns LOGIN, then the controller should be able to
return headers that correspond to showing the log-in prompt, or one
could simply have a view mapped to LOGIN that returns those headers. Or am I missing something?

Can this be done? I'm not sure... I think this would require
container-specific code for each container we support.
Isn't just a case of returning standard HTTP headers? (for the prompt I mean).

Also, what should happen if an action is invoked through an <include> and is not allowed access to. This is by far the most common case I have anyway (I don't have ANY other case). How would that work?

/Rickard

--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic

Got blog? I do. http://dreambean.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


Reply via email to