Hi May I ask you what version av Cocoon you are using? I ask because the documentation you are refering to is somewhat outdated if you are using 1.2.10 (may be even for 1.2.9). I found out that in version 1.2.10 Cocoon is set up to use the new CoWarp authetication framwork (Which is a better one). But things are different when using that. If you look at your cocoon.xconf, you can find the following : "If you want to use the authentication framework, comment out the above line and uncomment the following line:"
Hope this helps. Regards, Armaz > -----Original Message----- > From: Peter Flynn [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 10, 2007 10:42 AM > To: users@cocoon.apache.org > Subject: Re: Authentication puzzle > > Steven D. Majewski wrote: > > > My understanding is that the Authentication Framework is just a > > framework -- it doesn't itself do any authentication or > > encryption/decryption of passwords. > > I understand that it doesn't do any authentication: that's > what I wrote the little XML and XSLT files for: to output the > format specified in the doc at > http://cocoon.apache.org/2.1/developing/webapps/authentication.html > > I did, however, expect it to pass the password in crypt(3) > form, but that's not important for now. > > > It manages protected resources and restricts them to authenticated > > users. ( Because typically sites will want to plug in different > > authentication mechanisms. ) > > Yes, that much I'm happy with. I'll eventually want this to > authenticate against Active Directory or an LDAP server. > > > I'm not clear on what you're trying to do. Are you doing > trying to do > > HTTP Basic Authentication ? > > For now I just want to authenticate using the little file I > posted, which provides a username and password per user that > I can match against locally. > > I'm not sure what "HTTP Basic Authentication" is (unless it's > like the method used by regular Apache httpd for web > passwords -- but that *does* use crypt(3)). I'm using the > file system: my auth.xml and auth.xsl with the > parameter_username and parameter_password as per the document > image in > http://cocoon.apache.org/2.1/developing/webapps/authentication.html > > <map:match pattern="login"> > <map:generate src="auth.xml"/> > <map:transform src="auth.xsl" type="xslt"> > <map:parameter name="use-request-parameters" value="true"/> > </map:transform> > <map:serialize type="xml"/> > </map:match> > > > And I'm not sure what you mean by "required crypt(3)" - > required by whom ? > > Me. I assumed (obviously wrongly) that Cocoon would handle > the encryption of the password. No matter -- for the moment I > don't care; but the problem still stands in that it isn't > coming back with authentication when I provide the right > userid/password pair in Cocoon, but it *does* provide the > specified output if I perform the same action from the shell > commandline using Saxon. > > > HTTP Basic Authentication sends the bas64 encoding of > "user:password" > > They aren't encrypted. > > Base64? Ewww. So if I store the userid and password in my XML > disk file in base64 encoding they should be matched? > > > ( But if you're trying to port users from an Apache > .htpasswd file , > > then THOSE entries are encrypted with crypt(3). That was my problem > > and I found and adapted a javascript version of crypt. ) > > No, I wasn't trying to use those: I just assumed the concept > would be the same, only performed by my XML file and its XSLT > procedure. > > The documentation is missing this vital information in that case. > > Has anyone ever implemented a small test case where > authentication is performed by a component which just runs > XSLT over XML and matches the passed userid/password > parameters with values in the XML file, and returns the > format specified in the Cocoon doc at > http://cocoon.apache.org/2.1/developing/webapps/authentication.html > > ///Peter > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
