cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sonny Sukumar" <>
Subject Re: 3 questions...
Date Wed, 20 Aug 2003 07:05:36 GMT

>From: Andrew Timberlake <>
>I didn't have the answers to your questions immediately but I have done 
>some digging throught he source code and can hopefully give you a head 
>start on your understanding...

Andrew, thank you for your time and effort to find the info below for *is* proving helpful.  See couple questions below...

>Sonny Sukumar wrote:
>>[2 of these questions I sent a couple days ago but got no reply and 
>>haven't figured them out.  They pertain to Cocoon's Authentication 
>>Framework. Thanks.]
>>These 3 questions are based on this doc: 
>>1.) The doc states "If the authentication is successful, a session object 
>>is created on the server (if not already done).  If the authentication 
>>fails, the error information delivered by the authentication resource is 
>>stored into the temporary context (which is named simply 'temp')."
>>Question: Where is this 'temp' context stored, if not in the session?
>The temporary context is stored in the session and it is stored with the 
>key "temporary" or more specifically in the 
>you will find reference to the SessionConstants.TEMPORARY_CONTEXT being 
>used. This is used in conjunction with the SessionManager.

Interesting, I did suppose it had to be stored in the session, even though 
the docs were a bit ambiguous.  From what I see in the API, it looks like 
PipelineAuthenticator is a helper class that AuthAction (referenced by 
"auth-protect") in the sitemap probably uses--although I'm not really 
familar with Cocoon's current class architecture, so I have no idea.

In any case, the details you provided are quite helpful.

>>2.) Where is the "login" tag of the login resource referred to in this 
>>'If the authentication is not successful, the resource must create an XML 
>>with the root node "authentication". In addition a "data" node can be 
>>added containing more information about the unsuccessful attempt. **This 
>>data node is then added inside the "login" tag of the login resource.**'
>I'm not sure that a login tag is created. The temprary context should 
>contain an XML fragment which looks like the following:
>     <failed/>
>     <data>Any error message which was set by your authentication 
>This I get from reading the few lines above the 
>SessionConstants.TEMPORARY_CONTEXT code I mentioned above.

Ahh, that's strange...the docs mention nothing about a <failed/> tag from 
what I read.  Is this just a tagging element of some sort?  I mean, is it 
just always an empty element that just signals the authentication failed?

>>3.) Is it necessary to use the "raw:" subprotocol here for not forwarding 
>>request params?  As in:
>>   <handler name="unique">
>>      <!-- The login resource -->
>>      <redirect-to uri="cocoon:raw://loginpage"/>
>>      <authentication uri="cocoon:raw://authenticationresource"/>
>>    </handler>
>>It says "...this resource is requested by the framework with the given 
>>parameters from the auth-login action" referring to the authentication 
>>resource, so perhaps the "raw:" subprotocol is there to prevent duplicate 
>>request params?  I'm just guessing here...
>I'll leave you to your guess here.

Hehe ok.

>I hope I've at least been able to provide a little help.

Most definitely.  Thanks again, Andrew!

>><b>Get MSN 8</b> and enjoy automatic e-mail virus protection.   
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

<b>Get MSN 8</b> and help protect your children with advanced parental 

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

View raw message