You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Ted Husted (JIRA)" <ji...@apache.org> on 2006/10/12 13:31:32 UTC
[jira] Commented: (WW-1469) Canonical or example app-based,
role-based authentication methodology
[ http://issues.apache.org/struts/browse/WW-1469?page=comments#action_38374 ]
Ted Husted commented on WW-1469:
--------------------------------
To get started, I would suggest creating an interceptor and interface combination that exposed a security role property on the Action. The property could be set using
<action ... >
<param name="role">manager</param>
without changing the DTD.
Once the interceptor/interface was available, then we could decide if it is something that could be added to the DTD. In the meantime, it would be available for use in an application.
-Ted.
> Canonical or example app-based, role-based authentication methodology
> ---------------------------------------------------------------------
>
> Key: WW-1469
> URL: http://issues.apache.org/struts/browse/WW-1469
> Project: Struts 2
> Issue Type: New Feature
> Affects Versions: 2.0.2
> Reporter: Dave Newton
> Priority: Minor
>
> Rather than implementing full-blown Acegi access control it would be nice if there was a built-in way to do simple role-based authentication from within the application, similar to how we used to override processRoles in Struts1.
> This might be as easy as adding a csvRoles (or whatever) getter to ActionSupport to imply a default param for setting an Action's allowable roles and supplying a canned, configurable interceptor that would process it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira