Skip Menu |

This queue is for tickets about the Apache-AuthCookie CPAN distribution.

Report information
The Basics
Id: 13489
Status: resolved
Priority: 0/
Queue: Apache-AuthCookie

People
Owner: MSCHOUT [...] cpan.org
Requestors: Henry.Baragar [...] instantiated.ca
Cc: mschout [...] gkg.net
AdminCc:

Bug Information
Severity: Important
Broken in: 3.08
Fixed in: 3.09_01



Subject: Credentials lost when sent back to login form
CC: mschout [...] gkg.net
Hi Henry. It was a pleasure to talk with you at YAPC. I am entering the bug you brought to my attention at YAPC with AuthCookie into the CPAN bug tracking system for tracking purposes. I am looking into this and will let you know what I find. Bug: when sent back to the login form (e.g.: due to bad_credentials), the original credentials are not available. Michael Schout
I have reproduced this, and I see whats going on. The issue is that _convert_to_get() discards the login data. The reason it does this is because _convert_to_get() is called from both login(), and from login_form(). If the login data was kept in there, the "destination" parameter would get destination, credential_0, credential_1 (etc) appeneded to it every time the browser is sent back to the login form. So at the first login form, the destination (constructed from $r->prev->uri, and $r->prev->args) might be: /foo?session_id=12345 after a failed login attempt it might be: /foo/session_id=12345&destination=...&credential_0=foo&credential_1=bar after a second failed login attempt it would append destination, credential_0, credential_1 to it a second time and so on. What really needs to happen is that we need to be able to tell _convert_to_get() when it is okay to copy the login credentials (from login()), and when it is not (from login_form()). So I'll probably fix this by adding another parameter to _convert_to_get() that controls this behavior. This will be fixed in 3.09. Regards, Michael Schout
Henry: I have fixed this issue in Apache::AuthCookie 3.09_01. However, you still will not have the credentials in CGI.pm, or libapreq. There are 2 reasons why this is not possible: 1) LoginScript runs inside a subrequest. The POSTed form data comes from the *previous* request. From your LoginScript's perspective, the form data does not exist because the LoginScript is in a different Apache request. 2) Apache only allows you to read POST data ONE TIME. This happens inside AuthCookie. AuthCookie has no way of knowing if you are going to be using CGI.pm, libapreq, or some other form-data-library. So AuthCookie can not initialize CGI.pm, or libapreq for you. So the only thing that can be reasonably done is to provide an interface for the LoginScript to retrieve the credentials from the previous request. In 3.09_01, I have stored the @credentials array in $r->pnotes("${auth_name}Creds"); So in your LoginScript, you simply get the credentials this way: my $creds = $r->prev->pnotes("${auth_name}Creds"); If the creds are available, $creds will be defined, and is a reference to an array containing the credentials. See t/htdocs/docs/login.pl from 3.09_01 which makes use of this and includes the credentials in a HTML comment in the login form (so that real.t can check that it works :)). If you have any questions about this, please do not hesitate to contact me. Regards, Michael Schout