You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Andrew Stevens <at...@hotmail.com> on 2006/05/24 00:50:44 UTC
RE: Authentication-fw: two quick questions
>From: footh <fo...@yahoo.com>
>Date: Tue, 23 May 2006 10:22:59 -0700 (PDT)
>
>I've newly implemented cocoon's auth-fw and have a
>couple of questions.
Unfortunately, I've not used the auth framework much, so I can't help with
the first one.
>The second question has to do with roles. I have a
>protected area which has an admin section that only
>users with the "admin" role can access. Are there any
>creative solutions for getting this to work with just
>one auth handler? I'd like for the user to only have
>to login once (ie, not use a separate "admin
>handler").
RoleFilterTransformer, maybe?
It'd be a bit tricky integrating that with the auth-fw, though, as it uses
the request's isUserInRole method rather than the authentication context the
auth-fw provides. You could always create a servlet filter that extracts
the auth information from the session and overrides isUserInRole in a
request wrapper. Or just use the RoleFilterTransformer as the basis for a
similar transformer that uses the role information from the context instead
of isUserInRole.
Alternatively, you can use the session transformer to extract any role
information from the authentication context, then use it in an XSL template
to filter out other elements if the required role isn't in it. See "Getting
information from the context" in
http://cocoon.apache.org/2.1/developing/webapps/authentication/user_management.html
Hope this helps,
Andrew.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Authentication-fw: two quick questions
Posted by footh <fo...@yahoo.com>.
Andrew, thanks again for the help. I actually did
come up with a nice solution. I created a custom
Selector called "RoleSelector". The content of the
select method is simply this:
boolean bResult = false;
try {
ContextManager contextMgr =
(ContextManager)manager.lookup(ContextManager.ROLE);
AuthenticationContext authContext =
(AuthenticationContext)contextMgr.getContext(AuthenticationConstants.SESSION_CONTEXT_NAME);
if (authContext != null) {
bResult = authContext.isUserInRole(expression);
}
}
catch (Exception e) {
}
return bResult;
Then, in the sitemap, I can use this:
<map:match pattern="admin/**">
<map:act type="auth-protect">
<map:parameter name="handler"
value="member-handler"/>
<map:select type="roles">
<map:when test="Admin">
<map:mount check-reload="yes"
src="app_admin/" uri-prefix="admin"/>
</map:when>
<map:otherwise>
<map:generate
src="documents/errors/unauthorized.html"/>
<map:serialize status-code="403"/>
</map:otherwise>
</map:select>
</map:act>
</map:match>
Now, I just need a solution for the other problem.
--- Andrew Stevens <at...@hotmail.com> wrote:
> >From: footh <fo...@yahoo.com>
> >Date: Wed, 24 May 2006 09:24:51 -0700 (PDT)
> >
> >Thanks for the reply.
> >
> >I was hoping for something a little bit simpler
> than
> >creating or modifying a transformer, like something
> >that was configurable in the sitemap. I'll take a
> >look at those options though.
>
> Another option I've thought of - according to
>
http://cocoon.apache.org/2.1/developing/webapps/authentication/pipeline_patterns.html
> "The auth-protect action returns - if the user is
> logged in for the given
> handler - all values from the context to the
> sitemap, e.g. ID, role etc.
> These values can be used within the other
> components"
> So you should then be able to use the
> ParameterSelector to choose a
> different pipeline for admin users with (I think)
>
> ...
> <map:act type="auth-protect">
> <map:select type="parameter">
> <map:parameter name="parameter-selector-test"
> value="{role}"/>
> <map:when test="admin">
> <map:transform src="admin.xsl"/>
> </map:when>
> <map:otherwise>
> <map:transform src="ordinary_user.xsl"
> </map:otherwise>
> </map:select>
> </map:act>
> ...
>
>
> Andrew.
>
>
> >Every page flows through a single javaflow so I
> could
> >check for the Admin role there and control access
> to
> >pages in the admin section. However, that would
> >require me to hardcode the admin directory in code
> >which I would hate to do.
> >
> >I do pass a variable to the pages if the user is an
> >adminstrator so based on your suggestion, I might
> be
> >able to do something with that. I'll give it a
> try.
> >
> >--- Andrew Stevens <at...@hotmail.com> wrote:
> >
> > > >From: footh <fo...@yahoo.com>
> > > >Date: Tue, 23 May 2006 10:22:59 -0700 (PDT)
> > > >
> > > >I've newly implemented cocoon's auth-fw and
> have a
> > > >couple of questions.
> > >
> > > Unfortunately, I've not used the auth framework
> > > much, so I can't help with
> > > the first one.
> > >
> > > >The second question has to do with roles. I
> have a
> > > >protected area which has an admin section that
> only
> > > >users with the "admin" role can access. Are
> there
> > > any
> > > >creative solutions for getting this to work
> with
> > > just
> > > >one auth handler? I'd like for the user to
> only
> > > have
> > > >to login once (ie, not use a separate "admin
> > > >handler").
> > >
> > > RoleFilterTransformer, maybe?
> > > It'd be a bit tricky integrating that with the
> > > auth-fw, though, as it uses
> > > the request's isUserInRole method rather than
> the
> > > authentication context the
> > > auth-fw provides. You could always create a
> servlet
> > > filter that extracts
> > > the auth information from the session and
> overrides
> > > isUserInRole in a
> > > request wrapper. Or just use the
> > > RoleFilterTransformer as the basis for a
> > > similar transformer that uses the role
> information
> > > from the context instead
> > > of isUserInRole.
> > >
> > > Alternatively, you can use the session
> transformer
> > > to extract any role
> > > information from the authentication context,
> then
> > > use it in an XSL template
> > > to filter out other elements if the required
> role
> > > isn't in it. See "Getting
> > > information from the context" in
> > >
>
>http://cocoon.apache.org/2.1/developing/webapps/authentication/user_management.html
> > >
> > > Hope this helps,
> > >
> > >
> > > Andrew.
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail:
> users-help@cocoon.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Authentication-fw: two quick questions
Posted by Andrew Stevens <at...@hotmail.com>.
>From: footh <fo...@yahoo.com>
>Date: Wed, 24 May 2006 09:24:51 -0700 (PDT)
>
>Thanks for the reply.
>
>I was hoping for something a little bit simpler than
>creating or modifying a transformer, like something
>that was configurable in the sitemap. I'll take a
>look at those options though.
Another option I've thought of - according to
http://cocoon.apache.org/2.1/developing/webapps/authentication/pipeline_patterns.html
"The auth-protect action returns - if the user is logged in for the given
handler - all values from the context to the sitemap, e.g. ID, role etc.
These values can be used within the other components"
So you should then be able to use the ParameterSelector to choose a
different pipeline for admin users with (I think)
...
<map:act type="auth-protect">
<map:select type="parameter">
<map:parameter name="parameter-selector-test" value="{role}"/>
<map:when test="admin">
<map:transform src="admin.xsl"/>
</map:when>
<map:otherwise>
<map:transform src="ordinary_user.xsl"
</map:otherwise>
</map:select>
</map:act>
...
Andrew.
>Every page flows through a single javaflow so I could
>check for the Admin role there and control access to
>pages in the admin section. However, that would
>require me to hardcode the admin directory in code
>which I would hate to do.
>
>I do pass a variable to the pages if the user is an
>adminstrator so based on your suggestion, I might be
>able to do something with that. I'll give it a try.
>
>--- Andrew Stevens <at...@hotmail.com> wrote:
>
> > >From: footh <fo...@yahoo.com>
> > >Date: Tue, 23 May 2006 10:22:59 -0700 (PDT)
> > >
> > >I've newly implemented cocoon's auth-fw and have a
> > >couple of questions.
> >
> > Unfortunately, I've not used the auth framework
> > much, so I can't help with
> > the first one.
> >
> > >The second question has to do with roles. I have a
> > >protected area which has an admin section that only
> > >users with the "admin" role can access. Are there
> > any
> > >creative solutions for getting this to work with
> > just
> > >one auth handler? I'd like for the user to only
> > have
> > >to login once (ie, not use a separate "admin
> > >handler").
> >
> > RoleFilterTransformer, maybe?
> > It'd be a bit tricky integrating that with the
> > auth-fw, though, as it uses
> > the request's isUserInRole method rather than the
> > authentication context the
> > auth-fw provides. You could always create a servlet
> > filter that extracts
> > the auth information from the session and overrides
> > isUserInRole in a
> > request wrapper. Or just use the
> > RoleFilterTransformer as the basis for a
> > similar transformer that uses the role information
> > from the context instead
> > of isUserInRole.
> >
> > Alternatively, you can use the session transformer
> > to extract any role
> > information from the authentication context, then
> > use it in an XSL template
> > to filter out other elements if the required role
> > isn't in it. See "Getting
> > information from the context" in
> >
>http://cocoon.apache.org/2.1/developing/webapps/authentication/user_management.html
> >
> > Hope this helps,
> >
> >
> > Andrew.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Authentication-fw: two quick questions
Posted by footh <fo...@yahoo.com>.
Thanks for the reply.
I was hoping for something a little bit simpler than
creating or modifying a transformer, like something
that was configurable in the sitemap. I'll take a
look at those options though.
Every page flows through a single javaflow so I could
check for the Admin role there and control access to
pages in the admin section. However, that would
require me to hardcode the admin directory in code
which I would hate to do.
I do pass a variable to the pages if the user is an
adminstrator so based on your suggestion, I might be
able to do something with that. I'll give it a try.
--- Andrew Stevens <at...@hotmail.com> wrote:
> >From: footh <fo...@yahoo.com>
> >Date: Tue, 23 May 2006 10:22:59 -0700 (PDT)
> >
> >I've newly implemented cocoon's auth-fw and have a
> >couple of questions.
>
> Unfortunately, I've not used the auth framework
> much, so I can't help with
> the first one.
>
> >The second question has to do with roles. I have a
> >protected area which has an admin section that only
> >users with the "admin" role can access. Are there
> any
> >creative solutions for getting this to work with
> just
> >one auth handler? I'd like for the user to only
> have
> >to login once (ie, not use a separate "admin
> >handler").
>
> RoleFilterTransformer, maybe?
> It'd be a bit tricky integrating that with the
> auth-fw, though, as it uses
> the request's isUserInRole method rather than the
> authentication context the
> auth-fw provides. You could always create a servlet
> filter that extracts
> the auth information from the session and overrides
> isUserInRole in a
> request wrapper. Or just use the
> RoleFilterTransformer as the basis for a
> similar transformer that uses the role information
> from the context instead
> of isUserInRole.
>
> Alternatively, you can use the session transformer
> to extract any role
> information from the authentication context, then
> use it in an XSL template
> to filter out other elements if the required role
> isn't in it. See "Getting
> information from the context" in
>
http://cocoon.apache.org/2.1/developing/webapps/authentication/user_management.html
>
> Hope this helps,
>
>
> Andrew.
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail:
> users-help@cocoon.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org