You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Dave Newton <DN...@hibbertgroup.com> on 2006/10/11 17:50:03 UTC
[Struts2] Canonical application-based, role-based authentication.
What *is* the canonical way to do app- and role-based authentication
like I used to with a custom RequestProcessor in Struts1?
The way I have it now is via an action param with a csv list of roles
and an interceptor that expects all actions to implement a getter for
that parameter.
I know there's the Acegi route, but I'm already getting yelled at
because they found out Struts2 uses Spring and I was only allowed to use
one new technology :/
I think Acegi might make them cut out their own spleens, but if it's the
"best" option then I'll hand 'em the knife myself.
TIA,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Struts2] Canonical application-based, role-based authentication.
Posted by Don Brown <do...@gmail.com>.
Haha, one new library at a time, eh? Well, this is a common request
that also came up in the presentation I just gave to ApacheCon on
Struts 2. I think we should come up with a solution. Please put in a
feature request and mark its fix version as 2.0.2.
Thanks,
Don
On 10/11/06, Wesslan <fo...@wesslan.se> wrote:
> I don't know the answer to your question but Acegi *is* a Spring subproject
> and will be renamed "Spring security". So now you only use ONE new
> technology... :)
>
> -----Original Message-----
> From: Dave Newton [mailto:DNewton@hibbertgroup.com]
> Sent: den 11 oktober 2006 17:50
> To: Struts Users Mailing List
> Subject: [Struts2] Canonical application-based, role-based authentication.
>
> What *is* the canonical way to do app- and role-based authentication
> like I used to with a custom RequestProcessor in Struts1?
>
> The way I have it now is via an action param with a csv list of roles
> and an interceptor that expects all actions to implement a getter for
> that parameter.
>
> I know there's the Acegi route, but I'm already getting yelled at
> because they found out Struts2 uses Spring and I was only allowed to use
> one new technology :/
>
> I think Acegi might make them cut out their own spleens, but if it's the
> "best" option then I'll hand 'em the knife myself.
>
> TIA,
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: [Struts2] Canonical application-based, role-based authentication.
Posted by Wesslan <fo...@wesslan.se>.
I don't know the answer to your question but Acegi *is* a Spring subproject
and will be renamed "Spring security". So now you only use ONE new
technology... :)
-----Original Message-----
From: Dave Newton [mailto:DNewton@hibbertgroup.com]
Sent: den 11 oktober 2006 17:50
To: Struts Users Mailing List
Subject: [Struts2] Canonical application-based, role-based authentication.
What *is* the canonical way to do app- and role-based authentication
like I used to with a custom RequestProcessor in Struts1?
The way I have it now is via an action param with a csv list of roles
and an interceptor that expects all actions to implement a getter for
that parameter.
I know there's the Acegi route, but I'm already getting yelled at
because they found out Struts2 uses Spring and I was only allowed to use
one new technology :/
I think Acegi might make them cut out their own spleens, but if it's the
"best" option then I'll hand 'em the knife myself.
TIA,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org