cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Fiol Bonnín <>
Subject Re: Trying to implement two-phase authentication with flow
Date Mon, 19 Dec 2005 10:03:26 GMT
2005/12/15, Stan Dyck <>:
> On Wed, 2005-12-14 at 15:52 +0100, Antonio Fiol Bonnín wrote:
> > 2005/12/13, Stan Dyck <>:
> > > The question is how to do a lookup for the content of the second page
> > > after the sendPageAndWait call in my flowscript. My script calls the
> > > login method on an AuthenticationManager to verify authentication. I use
> > > this as my check for passing onto the second phase, so I figured that
> > > I'd have an authentication context that I could pull data from. But I
> > > can't figure out how to access this context (or any other, for that
> > > matter) from within a flowscript.
> >
> > Not sure if it may help, but I have this code on my app, and it is working.
> >
> > ...
> >     var contextMan =
> > cocoon.getComponent(;
> >     var authContext = contextMan.getContext("authentication");
> >     if(authContext!=null) {
> >         var userFrag = authContext.getXML("/authentication/ID");
> >         var username =
> >;
> >         // Obtenemos la informacion de permisos de la sesión
> >         var userData = authContext.getXML("/authentication/data/permisos");
> > ...
> >
> > HTH,
> >
> > --
> > Antonio
> Thanks, Antonio!
> I was actually taking this approach with some success until I realized
> that I had a Mack truck-sized hole in my approach. I'll detail below for
> the archives.
> The flowscript function for the first form in the two phase
> authentication was calling the login method of the
> AuthenticationManager. This allowed me to verify a user name and
> password and look up information for the second phase form. The problem
> is that it appears that once the login method is called and returns a
> non-null value, as far as cocoon is concerned, the user is
> authenticated; a session is generated and an authentication context
> exists. That means that a user can bypass the second phase form and go
> directly to protected content.
> My workaround has been to write a separate authenticating class that
> does not use the login method. The first form uses this custom class to
> verify user id/password credentials. The second form then uses the user
> id to construct the second form. When the second form is successfully
> processed, the login method is called and the authentication context is
> constructed.
> I realize I'm a little light on details here, but if anyone has bothered
> to read to this point and sees any glaring holes in this approach, I'd
> appreciate it if you'd let me know.


I'm not sure, but couldn't you use login+logout in your first
processing function, and login in the second?

Other than that, you can check for certain data in the authentication
context, so you could maybe use login in the first form, and fill the
data when processing the second. But that would mean that you need to
protect your resources with something like:
      <map:match pattern="pattern_of_resource_used_by_user">
        <map:act type="auth-protect">
          <map:parameter name="handler" value="auth-handler"/>
          <map:call function="autorizacion">
            <map:parameter name="resource" value="{../0}" />
<map:pipeline internal-only="true">
      <map:match pattern="protected/pattern_of_resource_used_by_user">
        ... whatever you need to do to serve your resource ...

the "autorizacion" function looks in the authentication context for
specific data and redirects to "protected/{resource}" if the check is

This approach allowed me to use the authentication framework for
authentication, but use a fine grained authorization scheme in a
fairly simple way.

So in case a user is authenticated but not authorized to do what he
wants, I send him to a special login form which says "Hey, I know who
you are, and you cannot do what you want to do. Log in as another user
or go away!" in a polite way.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message