Peter and others,
concerning the authentication resource, I eventually found the following in core.log:
DEBUG (2005-04-30) 15:28.26:711 [core.authentication-manager] (/sopas/do-login) http-8080-Processor25/PipelineAuthen
ticator: BEGIN isValidAuthenticationFragment fragment=<?xml version="1.0" encoding="UTF-8"?>
DEBUG (2005-04-30) 15:28.26:711 [core.authentication-manager] (/sopas/do-login) http-8080-Processor25/PipelineAuthen
ticator: END isValidAuthenticationFragment valid=false
INFO (2005-04-30) 15:28.26:711 [core.authentication-manager] (/sopas/do-login) http-8080-Processor25/PipelineAuthen
ticator: Authenticator: Failed authentication using handler 'sopashandler'
I think what is happening is the authenticator does not accepts a <?xml version="1.0" encoding="UTF-8"?> in the XML document that is being returned by the authentication resource. This would automatically explain why the authentication -always- fails.
Can somebody confirm this? The native XML database returns valid XML document, always including <?xml version="1.0" encoding="UTF-8"?>.
Thanks, Andre
Andre Juffer wrote:
Peter,
I have included more information from the sitemap.log:
DEBUG (2005-04-29) 21:06.40:685 [sitemap] (/sopas/do-login) http-8080-Processor24/AbstractCachingProcessingPipeline:
processXMLPipeline: caching content for further requests of 'authenticate.xxx' using key PK_G-file-cocoon://persistence
/[EMAIL PROTECTED] &pipelinehash=-1143565400972049993_T-xslt-file:/wrkhuge/webapps/jakarta-tomcat-5.5
.7/webapps/sopas/accounts/docs/xsl/authenticate.xsl;password=qwerty12 ;[EMAIL PROTECTED] ;use-request-paramete
rs=true
DEBUG (2005-04-29) 21:06.40:685 [sitemap.generator.file] (/sopas/do-login) http-8080-Processor24/FileGenerator: Sour
ce cocoon://persistence/[EMAIL PROTECTED] resolved to cocoon://persistence/get-party?email=andre.juf
[EMAIL PROTECTED] &pipelinehash=-1143565400972049993
DEBUG (2005-04-29) 21:06.40:686 [sitemap] (/sopas/do-login) http-8080-Processor24/AbstractCachingProcessingPipeline:
processXMLPipeline: caching content for further requests of 'get-party' using key PK_G-file-cocoon://persistence/sopas/
parties/?xpath=/party[email='[EMAIL PROTECTED] ']
DEBUG (2005-04-29) 21:06.40:686 [sitemap.generator.file] (/sopas/do-login) http-8080-Processor24/FileGenerator: Sour
ce cocoon://persistence/sopas/parties/?xpath=/party[email='[EMAIL PROTECTED] '] resolved to cocoon://persistence/sopa
s/parties/?xpath=/party[email='[EMAIL PROTECTED] ']
DEBUG (2005-04-29) 21:06.40:686 [sitemap.generator.file] (/sopas/do-login) http-8080-Processor24/FileGenerator: Sour
ce xmldb:xindice://claudius.oulu.fi:8080/db/sopas/parties/#/party[email='[EMAIL PROTECTED] '] resolved to xmldb:xindi
ce://claudius.oulu.fi:8080/db/sopas/parties/
DEBUG (2005-04-29) 21:06.40:766 [sitemap] (/sopas/do-login) http-8080-Processor24/ResourceLimitingPool: Put a org.ap
ache.cocoon.generation.FileGenerator back into the pool.
...
...
DEBUG (2005-04-29) 21:06.40:768 [sitemap] (/sopas/do-login) http-8080-Processor24/LoginAction: END act map=null
INFO (2005-04-29) 21:06.40:768 [sitemap] (/sopas/do-login) http-8080-Processor24/RedirectToURINode: Redirecting to
'login' at file:/wrkhuge/webapps/jakarta-tomcat-5.5.7/webapps/sopas/sitemap.xmap:772:39
It shows that it actually DOES contact the authentication resource with the request parameters 'userid' and 'password'. It also goes into the database (currently a very simple procedure to read an entry from an native XML database, see the line with 'persistence' below). The XSLT tranformer uses the authenticate.xsl with the correct parameters (it simply compares the passwords).
The sitemap in the accounts directory contains a very simple and straightforward entry:
<map:match pattern="authenticate.xxx"> <map:match type="request-parameter" pattern="userid"> <map:generate src="cocoon://persistence/get-party?email={1}" /> <map:transform src="docs/xsl/authenticate.xsl"> <map:parameter name="use-request-parameters" value="true" /> </map:transform> <map:serialize type="xml" /> </map:match> </map:match>
As I have indicated in a previous email, this 'authenticate.xxx' resource works perfectly well when called manually (with the same set of request parameters), so it SHOULD work as well when called by the authentication-fw.
What I don't see currently is an entry coming from the <map:serialize type="xml" />, while also the order of appearance of log messages is somewhat confusing. The log also clearly shows that map=null is returned by the LoginAction. This should not be.
Do you see anything unusual?
Andre.
[EMAIL PROTECTED] wrote:
Andre Juffer <[EMAIL PROTECTED]> wrote on 29-04-2005 17:51:31:
Peter,
thanks for your reply. I have tried your suggestion, but it has no effect. From the sitemap.log, I cannot see any attempt to contact the authentication resource. It just indicates:
INFO (2005-04-29) 18:38.13:472 [sitemap] (/sopas/do-login.xxx) http-8080-Processor25/ForwardRedirector: Redirecting to 'login'
So, it went correctly to do-login.xxx resource, but as far as I can see it never attempts to contact the authentication resource. I would have expected an entry in the log file about this. There is an entry in the core.log:
INFO (2005-04-29) 18:38.13:470 [core.authentication-manager] (/sopas/do-login.xxx) http-8080-Processor25/PipelineAuthenticator: Authenticator: Failed authentication using handler 'sopashandler'
So, something is not working. Given the fact that the authentication resource works, when I call it manually, I suspect an error in the sitemap somewhere:
<map:pipelines> ... <map:component-configurations> <authentication-manager> <handlers> <handler name="sopashandler"> <redirect-to uri="cocoon:/login" /> <authentication uri="cocoon:raw:/accounts/authenticate" /> </handler> </handlers> </authentication-manager> </map:component-configurations> -- </map:pipelines>
Is the <map:component-configurations> in fact at the right location in the sitemap? There are a few typing errors in the documentation.
As far as I can see, this is correct. Here's mine: <map:pipelines> <map:component-configurations> <authentication-manager> <handlers> <handler name="mchandler"> <redirect-to uri="cocoon:/rvd/login.html" /> <authentication uri="cocoon:raw:/rvd/authenticate.xxx" /> </handler> </handlers> </authentication-manager> </map:component-configurations> ... </map:pipelines> I see no real difference. I think we need more info from the log. You can pump up the logging in WEB-INF/logkit.xconf. Change every log-level="..." to log-level="DEBUG". Restart Cocoon. Now you will see *a lot* more messsages in sitemap.log.
Regards, Peter
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Andre H. Juffer | Phone: +358-8-553 1161
The Biocenter and | Fax: +358-8-553-1141
the Dep. of Biochemistry | Email: [EMAIL PROTECTED]
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
