You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Pe...@mediacenter.nl on 2005/04/29 18:12:09 UTC
Betr.: Re: Betr.: authentication-fw
Andre Juffer <aj...@sun3.oulu.fi> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Betr.: Re: Betr.: Re: Betr.: Re: Betr.: authentication-fw
Posted by Pe...@mediacenter.nl.
Andre Juffer <aj...@sun3.oulu.fi> wrote on 02-05-2005 22:36:53:
> Peter.Urbanus@mediacenter.nl wrote:
> >
> >
> > In particular, what happens if you add the extra match <map:match
> > type="request-parameter" pattern="userid"> into your simplified
> > "authenticate" pipeline above?
>
> <map:match pattern="authenticate">
> <map:match type="request-parameter" pattern="userid">
> <map:generate src="/tmp/authenticate.xml" />
> <map:serialize type="xml" />
> </map:match>
> </map:match>
>
>
> Authentication works. But the same file is being used of course
> (/tmp/authenticate.xml), so it should work.
Agreed. I just wanted to exclude the possibility that this match didn't
"match".
And what happens if you add whitespace to your /tmp/authenticate.xml? In my
setup, I can add all the whitespace I like and it still works. So, assuming
it's not the whitespace, we have two pipelines
<map:match pattern="authenticate.xxx">
<map:match type="request-parameter" pattern="userid">
<map:generate src="/tmp/authenticate.xml" />
<map:serialize type="xml" />
</map:match>
</map:match>
and
<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>
First one works, second one doesn't.
Time to look at authenticate.xsl then? I would like to have a look at it.
There is one other thing you could do: use the LogTransformer to see the
SAX events. like this:
<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:transform type="log">
<map:parameter name="logfile" value="authenticate.log"/>
<map:parameter name="append" value="yes"/>
</map:transform>
<map:serialize type="xml" />
</map:match>
</map:match>
Regards, Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Betr.: Re: Betr.: Re: Betr.: authentication-fw
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
Peter.Urbanus@mediacenter.nl wrote:
>
>
> In particular, what happens if you add the extra match <map:match
> type="request-parameter" pattern="userid"> into your simplified
> "authenticate" pipeline above?
<map:match pattern="authenticate">
<map:match type="request-parameter" pattern="userid">
<map:generate src="/tmp/authenticate.xml" />
<map:serialize type="xml" />
</map:match>
</map:match>
Authentication works. But the same file is being used of course
(/tmp/authenticate.xml), so it should work.
>
> Cheers,
> Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
The Biocenter and | Fax: +358-8-553-1141
the Dep. of Biochemistry | Email: Andre.Juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Betr.: Re: Betr.: Re: Betr.: authentication-fw
Posted by Pe...@mediacenter.nl.
Andre Juffer <aj...@sun3.oulu.fi> wrote on 02-05-2005 22:06:16:
> Hi Peter,
>
> thanks again. I already experimented with a XML file earlier today. It
> is really ridiculous: if I save the XML document generated by the
> original authenticator to file as (e.g.) /tmp/authentication.xml and
> modify the sitemap to:
>
> <map:match pattern="authenticate">
> <map:generate src="/tmp/authenticate.xml" />
> <map:serialize type="xml" />
> </map:match>
>
> the authentication works fine!
Look at the other lines I wrote:
> > If this works (it must!) there are only three possibilities left (that
I
> > can think of):
> > - the extra match <map:match type="request-parameter" pattern="userid">
is
> > wrong
> > - something in authenticate.xsl
> > - something fishy in the XML produced by the XML database.
> > I've never worked with XML databases, so I can't help you there.
> >
In particular, what happens if you add the extra match <map:match
type="request-parameter" pattern="userid"> into your simplified
"authenticate" pipeline above?
Cheers,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Betr.: Re: Betr.: authentication-fw
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
Hi Peter,
thanks again. I already experimented with a XML file earlier today. It
is really ridiculous: if I save the XML document generated by the
original authenticator to file as (e.g.) /tmp/authentication.xml and
modify the sitemap to:
<map:match pattern="authenticate">
<map:generate src="/tmp/authenticate.xml" />
<map:serialize type="xml" />
</map:match>
the authentication works fine! NOTE AGAIN: The authenticate.xml is an
-exact- copy of the XML document produced by the orginal authenticator
with the two SAME request parameters password and userid that I have
used before! The only difference is that the result of the authenticator
is stored in a file. The content of the /tmp/authentication.xml is
<?xml version="1.0" encoding="ISO-8859-1"?>
<authentication>
<ID>1113937509670</ID>
<surname>juffer</surname>
<email>andre.juffer@oulu.fi</email>
<role>author</role>
</authentication>
(I have put things on separate lines for readability. The part after
<?xml version="1.0" encoding="ISO-8859-1"?> is on a single line in the
file.)
The core.log now correctly shows
DEBUG (2005-05-02) 22:42.45:311 [core.authentication-manager]
(/sopas/do-login) http-8080-Processor24/PipelineAuthen
ticator: BEGIN isValidAuthenticationFragment fragment=<?xml
version="1.0" encoding="UTF-8"?>
<authentication><ID>1113937509670</ID><surname>juffer</surname><email>andre.juffer@oulu.fi</email><role>author</role></a
uthentication>
Remember that with the original pipeline in the sitemap the part after
<?xml version="1.0" encoding="ISO-8859-1"?> is simply not available in
the PipelineAuthenticator. It should simply work!
Andre.
Peter.Urbanus@mediacenter.nl wrote:
>
>
>
>
> Andre Juffer <An...@oulu.fi> wrote on 02-05-2005 14:42:19:
>
>
>>Peter.Urbanus@mediacenter.nl wrote:
>>
>>>
>>>
>>>
>>>Andre Juffer <aj...@sun3.oulu.fi> wrote on 30-04-2005 14:52:29:
>>>
>>>
>>>
>>>>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"?>
>>>
>>>When the PipelineAuthenticator starts validating the XML fragment, it
>>>prints the entire fragment to the log. So at that point, your entire
>>>fragment is
>>> <?xml version="1.0" encoding="UTF-8"?>
>>>and nothing else, no <authentication> etc.
>>>
>>>Perhaps this helps?
>>
>>Actually, in the log file, there is an empty line just below
>>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"?>
>>
>>While the authenticator definitly returns the correct response (see
>>previous emails), the rest of the document is not available to the
>>PipelineAuthenticator, it apparently just gets the first line. By
>>looking at the source code of PipelineAuthenticator, I thought initially
>>that the <?xml version="1.0" encoding="UTF-8"?> should not be there,
>>just the XML itself, but this seems rubbish now.
>>
>>I guess I somehow need to get rid of new lines characters or spaces or
>>whatsoever in the returned XML document, so that the
>>PipelineAuthenticator sees one line only. Maybe that is the solution to
>>this. So, instead of
>>
>><?xml version="1.0" encoding="UTF-8"?>
>><authentication>
>>...
>></authentication>
>>
>>I would need to generate
>>
>><?xml version="1.0"
>
> encoding="UTF-8"?><authentication>...</authentication>
>
>>(this all is one line).
>>
>
> I would be surprised if it was the whitespace. But I have no explanation
> yet. So while nobody steps in and tells us what the problem is, we'll just
> have to stumble forward. Let's see what we have:
> - When you type ...authenticate.xxx in your browser, you get the right XML
> - When authenticate.xxx is called during authentication, it is mostly empty
> So there must be *some* difference. The only differences I can think of are
> request parameters. So you could test a situation where request parameters
> cannot screw you up. You could simply create an XML somedir/test.xml like
> this:
> <?xml version="1.0" encoding="UTF-8"?>
> <authentication>
> <ID>Me</ID>
> </authentication>
> And then change your sitemap like this:
> <map:match pattern="authenticate.xxx">
> <map:generate src="somedir/test.xml" />
> <map:serialize type="xml" />
> </map:match>
> If this works (it must!) there are only three possibilities left (that I
> can think of):
> - the extra match <map:match type="request-parameter" pattern="userid"> is
> wrong
> - something in authenticate.xsl
> - something fishy in the XML produced by the XML database.
> I've never worked with XML databases, so I can't help you there.
>
> Best of luck,
> Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
The Biocenter and | Fax: +358-8-553-1141
the Dep. of Biochemistry | Email: Andre.Juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Betr.: Re: Betr.: authentication-fw
Posted by Pe...@mediacenter.nl.
Andre Juffer <An...@oulu.fi> wrote on 02-05-2005 14:42:19:
> Peter.Urbanus@mediacenter.nl wrote:
> >
> >
> >
> >
> > Andre Juffer <aj...@sun3.oulu.fi> wrote on 30-04-2005 14:52:29:
> >
> >
> >>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"?>
> >
> > When the PipelineAuthenticator starts validating the XML fragment, it
> > prints the entire fragment to the log. So at that point, your entire
> > fragment is
> > <?xml version="1.0" encoding="UTF-8"?>
> > and nothing else, no <authentication> etc.
> >
> > Perhaps this helps?
>
> Actually, in the log file, there is an empty line just below
> 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"?>
>
> While the authenticator definitly returns the correct response (see
> previous emails), the rest of the document is not available to the
> PipelineAuthenticator, it apparently just gets the first line. By
> looking at the source code of PipelineAuthenticator, I thought initially
> that the <?xml version="1.0" encoding="UTF-8"?> should not be there,
> just the XML itself, but this seems rubbish now.
>
> I guess I somehow need to get rid of new lines characters or spaces or
> whatsoever in the returned XML document, so that the
> PipelineAuthenticator sees one line only. Maybe that is the solution to
> this. So, instead of
>
> <?xml version="1.0" encoding="UTF-8"?>
> <authentication>
> ...
> </authentication>
>
> I would need to generate
>
> <?xml version="1.0"
encoding="UTF-8"?><authentication>...</authentication>
>
> (this all is one line).
>
I would be surprised if it was the whitespace. But I have no explanation
yet. So while nobody steps in and tells us what the problem is, we'll just
have to stumble forward. Let's see what we have:
- When you type ...authenticate.xxx in your browser, you get the right XML
- When authenticate.xxx is called during authentication, it is mostly empty
So there must be *some* difference. The only differences I can think of are
request parameters. So you could test a situation where request parameters
cannot screw you up. You could simply create an XML somedir/test.xml like
this:
<?xml version="1.0" encoding="UTF-8"?>
<authentication>
<ID>Me</ID>
</authentication>
And then change your sitemap like this:
<map:match pattern="authenticate.xxx">
<map:generate src="somedir/test.xml" />
<map:serialize type="xml" />
</map:match>
If this works (it must!) there are only three possibilities left (that I
can think of):
- the extra match <map:match type="request-parameter" pattern="userid"> is
wrong
- something in authenticate.xsl
- something fishy in the XML produced by the XML database.
I've never worked with XML databases, so I can't help you there.
Best of luck,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Betr.: authentication-fw
Posted by Andre Juffer <An...@oulu.fi>.
Peter.Urbanus@mediacenter.nl wrote:
>
>
>
>
> Andre Juffer <aj...@sun3.oulu.fi> wrote on 30-04-2005 14:52:29:
>
>
>>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"?>
>
> When the PipelineAuthenticator starts validating the XML fragment, it
> prints the entire fragment to the log. So at that point, your entire
> fragment is
> <?xml version="1.0" encoding="UTF-8"?>
> and nothing else, no <authentication> etc.
>
> Perhaps this helps?
Actually, in the log file, there is an empty line just below
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"?>
While the authenticator definitly returns the correct response (see
previous emails), the rest of the document is not available to the
PipelineAuthenticator, it apparently just gets the first line. By
looking at the source code of PipelineAuthenticator, I thought initially
that the <?xml version="1.0" encoding="UTF-8"?> should not be there,
just the XML itself, but this seems rubbish now.
I guess I somehow need to get rid of new lines characters or spaces or
whatsoever in the returned XML document, so that the
PipelineAuthenticator sees one line only. Maybe that is the solution to
this. So, instead of
<?xml version="1.0" encoding="UTF-8"?>
<authentication>
...
</authentication>
I would need to generate
<?xml version="1.0" encoding="UTF-8"?><authentication>...</authentication>
(this all is one line).
What do you think?
Thanks,
Andre
> Regards,
> Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
The Biocenter and | Fax: +358-8-553-1141
the Dep. of Biochemistry | Email: Andre.Juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Betr.: authentication-fw
Posted by Pe...@mediacenter.nl.
Andre Juffer <aj...@sun3.oulu.fi> wrote on 30-04-2005 14:52:29:
> 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"?>
When the PipelineAuthenticator starts validating the XML fragment, it
prints the entire fragment to the log. So at that point, your entire
fragment is
<?xml version="1.0" encoding="UTF-8"?>
and nothing else, no <authentication> etc.
Perhaps this helps?
Regards,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
authentication-fw
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
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
> /get-party?email=andre.juffer@oulu.fi
> &pipelinehash=-1143565400972049993_T-xslt-file:/wrkhuge/webapps/jakarta-tomcat-5.5
>
> .7/webapps/sopas/accounts/docs/xsl/authenticate.xsl;password=qwerty12
> ;userid=andre.juffer@oulu.fi ;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/get-party?email=andre.juffer@oulu.fi resolved
> to cocoon://persistence/get-party?email=andre.juf
> fer@oulu.fi &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='andre.juffer@oulu.fi ']
> 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='andre.juffer@oulu.fi
> '] resolved to cocoon://persistence/sopa
> s/parties/?xpath=/party[email='andre.juffer@oulu.fi ']
> 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='andre.juffer@oulu.fi
> '] 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.
>
>
> Peter.Urbanus@mediacenter.nl wrote:
>
>>
>>
>>
>> Andre Juffer <aj...@sun3.oulu.fi> 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: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>
>
--
Andre H. Juffer | Phone: +358-8-553 1161
The Biocenter and | Fax: +358-8-553-1141
the Dep. of Biochemistry | Email: Andre.Juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Betr.: Re: Betr.: authentication-fw
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
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
/get-party?email=andre.juffer@oulu.fi
&pipelinehash=-1143565400972049993_T-xslt-file:/wrkhuge/webapps/jakarta-tomcat-5.5
.7/webapps/sopas/accounts/docs/xsl/authenticate.xsl;password=qwerty12
;userid=andre.juffer@oulu.fi ;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/get-party?email=andre.juffer@oulu.fi resolved
to cocoon://persistence/get-party?email=andre.juf
fer@oulu.fi &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='andre.juffer@oulu.fi ']
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='andre.juffer@oulu.fi
'] resolved to cocoon://persistence/sopa
s/parties/?xpath=/party[email='andre.juffer@oulu.fi ']
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='andre.juffer@oulu.fi
'] 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.
Peter.Urbanus@mediacenter.nl wrote:
>
>
>
> Andre Juffer <aj...@sun3.oulu.fi> 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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
The Biocenter and | Fax: +358-8-553-1141
the Dep. of Biochemistry | Email: Andre.Juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org