<snip>
You might be wondering why we explicitly pass the request parameters on to the internal pipeline call. Note that the authentication resource of the portalhandler is defined by cocoon:raw. By using this, no request parameter of the original request is passed on to the internal pipeline by default and therefore we have to define them explicitly. If you use cocoon: then the parameters of the form are by default passed on to the authentication resource and we could omit the parameter definition from above. But we feel that it is safer to explicitly define them.
</snip>
at: http://cocoon.apache.org/2.1/developing/webapps/authentication.html
If you use "cocoon:/" you're request parameters should be available in your xsp page.
On the other hand passing parameters to your handler should work also (so cocoon:raw can be used). But I see that your action is a bit wrong with parameter naming:
<snip>
<map:act type="auth-login">
<map:parameter name="handler" value="auth-handler"/>
<map:parameter name="param_username" value="{request-param:username}"/>
...</snip>
the docs say:
<snip> ...The name of this parameter has to start with "parameter_". ... </snip>
so try using <map:parameter name="parameter_username" value="..."/> instead (change names of other parameters as well of course ) to pass the parameters, then use them in your xsp without the prefix "parameter_".
I hope one of these remarks will solve your problem! ;-)
Kind Regards, Jan
Jon Tonberg wrote:
Hello all
I apologise in advance for the length of this email, but I'm at the "pulling hair out stage" with this one.
I wonder if anyone can help me out here - I'm having problems with authentication in Cocoon 2.1.6, (under Tomcat 4.1, Java 1.4.1).
In the past, I've successfully implemented sunrise authentication in previous versions of Cocoon (e.g. 2.0.4) but am struggling with one particular issue under 2.1.6.
I am using an XSP to implement my authentication handler. My specific problem is that the handler match cannot read the {request-param:XXX} parameters or any sitemap parameters instantiated by the login match.
The login match can see the request parameters POSTed from the login page, but if I then instantiate those as sitemap parameters, they cannot be read by the subsequent handler match.
Incidentally, if I hardcode the parameters in the handler match, the XSP runs correctly and authenticates using the hardcoded parameters, so it is not an XSP problem. The XSP tries to pick up the sitemap parameters (e.g. username and password). I have also tried to pick up the request object parameters from within the XSP - this does not work.
I don't remember having this issue with 2.0.4, but it's highly likely that I'm doing something silly here and just can't see it. Any pointers would be very welcome - I've trawled the mailing list archives, docs and wiki but don't seem to be getting any further.
To illustrate, here are some relevant snippets from my sitemap: -
<!-- AUTHENTICATION MANAGER -->
<authentication-manager> <handlers> <handler name="auth-handler"> <!-- login resource --> <redirect-to uri="cocoon:/login-page"/> <!-- authentication resource --> <authentication uri="cocoon:raw:/auth-user"/> </handler> </handlers> </authentication-manager>
<map:pipeline internal-only="true">
<!-- USER AUTH HANDLER -->
<map:match pattern="auth-user">
<map:generate type="serverpages" src="serverpages/auth-user.xsp">
<!-- PROBLEM - SITEMAP/REQUEST PARAMETERS ARE LOST AT THIS POINT -->
<!-- I'VE TRIED THREE DIFFERENT METHODS OF GETTING PARAMETERS TO
THE XSP ...
1. IF I HARD CODE THE PARAMETERS, THEN MY AUTHENTICATION
WORKS -->
<!--map:parameter name="param_username" value="XYZ"/>
<map:parameter name="param_password" value="XYZ"/-->
<!-- 2. USING THIS METHOD, PARAMETERS REMAIN UNINSTANTIATED -->
<map:parameter name="param_username" value="{param_username}"/>
<map:parameter name="param_password" value="{param_username}"/>
<!-- 3. USING THIS METHOD, PARAMETERS REMAIN UNINSTANTIATED -->
<!--map:parameter name="param_username" value="{request-param:username}"/>
<map:parameter name="param_password" value="{request-param:password}"/-->
</map:generate>
<map:serialize type="xml"/>
</map:match>
</map:pipeline>
<map:pipeline>
<!-- LOGIN FORM -->
<map:match pattern="login-page">
<map:generate src="deployed/xml/login.xml"/>
<map:transform type="xslt" src="stylesheets/application/login.xsl">
<map:parameter name="param_resource" value="{request-param:resource}"/>
<map:parameter name="param_username" value=""/>
<map:parameter name="param_fail" value="false"/>
</map:transform>
<map:serialize type="xhtml"/>
</map:match>
<!-- LOGIN FORM (AUTHENTICATION HAS ALREADY FAILED) -->
<map:match pattern="login-page-fail">
<map:generate src="deployed/xml/login.xml"/>
<map:transform type="xslt" src="stylesheets/application/login.xsl">
<map:parameter name="param_username" value="{request-param:username}"/>
<map:parameter name="param_resource" value="{request-param:resource}"/>
<map:parameter name="param_fail" value="true"/>
</map:transform>
<map:serialize type="xhtml"/>
</map:match>
<!-- LOGIN PROCESSOR (LOGIN FORM POSTS TO THIS MATCH) -->
<map:match pattern="login">
<map:act type="auth-login">
<map:parameter name="handler" value="auth-handler"/>
<!-- LOOKING AT THE COCOON LOGS, THESE REQUEST
PARAMS DO EXIST IN THE REQUEST OBJECT -->
<map:parameter name="param_username" value="{request-param:username}"/>
<map:parameter name="param_password" value="{request-param:password}"/> <!-- success -->
<map:redirect-to uri="{request-param:resource}"/>
</map:act>
<!-- failure -->
<map:redirect-to uri="cocoon:/login-page-fail"/>
</map:match>
<!-- EXAMPLE PROTECTED RESOURCE -->
<map:match pattern="index.html">
<map:act type="auth-protect">
<map:parameter name="handler" value="auth-handler"/>
<!-- DO PAGE DISPLAY -->
</map:act>
</map:match>
</map:pipeline>
Regards, jon
This electronic message contains information which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone on 0131 476 6000 and delete the material from your computer.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
