Jason Carreira wrote:
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.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).
Isn't just a case of returning standard HTTP headers? (for the prompt I mean).No, but the controller servlet can, I think. If the execution interceptor returns LOGIN, then the controller should be able toCan this be done? I'm not sure... I think this would require
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?
container-specific code for each container we support.
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