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 <[EMAIL PROTECTED]> wrote:
> >From: footh <[EMAIL PROTECTED]>
> >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 <[EMAIL PROTECTED]> wrote:
> >
> > > >From: footh <[EMAIL PROTECTED]>
> > > >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:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
