You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Adam Ratcliffe <ad...@prema.co.nz> on 2005/03/02 21:46:13 UTC

[repost] Problem with flow-based authentication

I've been re-implementing some code to use the flow functions in place of
actions for authentication and
have run into a problem with redirecting vs invoking an internal pipeline
once the user has successfully
logged in.

I have a protected pipeline declared in my sitemap:

      <map:match pattern="locations/*">
        <map:call function="protect">
	  	<map:parameter name="handler" value="webserviceHandler"/>
          	<map:parameter name="protected-internal"
value="internal/locations/{1}"/>
          	<map:parameter name="failure-redirect" value="login"/>
	</map:call>
      </map:match>

The login pipeline looks like this:

      <map:match pattern="login">
	<map:call function="login">
	  <map:parameter name="handler" value="webserviceHandler"/>
	  <map:parameter name="protected-internal"
value="{request-param:resource}"/>
	  <map:parameter name="failure-internal" value="challenge"/>
	</map:call>
      </map:match>

As you can see I'm requesting an internal 'redirection' if authentication is
successful using the original
request URI that has been set as the 'resource' parameter by the
authentication framework.  The issue is
that the original request URI contains the application context, for example:
'/smartfind/xml/locations/12345'.
For an external redirection the application segment of the path 'smartfind'
is matched by the HTTP server and
the top-level sitemap the resolves the remaining '/xml/locations/12345'
part, when this same URI is sent to the
top-level sitemap by sendPage() in the auth_checkAuthentication() function
it doesn't know what to do with the
'smartfind' segment.

I did consider changing the auth_checkAuthentication() function in auth.js
so that I could pass in my own
failure-redirect URI like:
'cocoon://xml/login?resource=internal/locations/{1}' but hesitated as this
seems
like a more general issue, potentially affecting others also.

Anyone else had this problem and come up with a satisfactory solution?

Cheers
Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org