From: Andrew Timberlake <[EMAIL PROTECTED]>
Sonny
Try walking the programming logic. Starting with org.apache.cocoon.webapps.authentication.acting.LoginAction
and follow how cocoon deals with each step of the process.
One thing to watch out for is when you get code such as manager.lookup(XXX.Role) this is referencing an Interface to which an implementation class has been assigned within cocoon.xconf. An easy way to identify the implementation class is to look for a class named in one of three common ways:
<NameOfInterface>Impl.java
Simple<NameOfInterface>.java
or
Default<NameOfInterface>.java
and then continue walking the logic. This is a great way to figure out how cocoon works internally which will help your use of cocoon considerably.
Oh, thanks for the tips. I did notice in general that the classes have at least somewhat meaningful names. ;-) There's just sooo many of them, and I'm not familiar with the Avalon framework/class architecture, component lifecycles, etc, so it's a bit daunting. Daunting, but never dull.... :-)
Sonny Sukumar wrote:Andrew, thank you for your time and effort to find the info below for me...it *is* proving helpful. See couple questions below...
I'm not sure that a login tag is created. The temprary context should contain an XML fragment which looks like the following:
<authentication>
<failed/>
<data>Any error message which was set by your authentication handler</data>
</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?
I think it is just a flag. Remember that this block is providing a generic process for handling authentication. Any block will try to provide a solution for the common problem but you don't need to use it to solve the problem in the way it was written specifically.
Example is that you need not check for the failed element to know that the auth failed as the action will pass the processing onto your failed pipeline fragment in which case, you simply need to retrieve the content of the data element and continue.
Tis true, Andrew. I'll see how all of this comes together when I actually try to implement something, which will be very soon. I'll report back if I have any difficulties I can't overcome.
Thanks again,
Sonny
Andrew
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
<b>Get MSN 8</b> and help protect your children with advanced parental controls. http://join.msn.com/?page=features/parental
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
