[Zope-PAS] CookieAuthHelper.

[Chris McDonough]

Hi folks,

I'd like to understand something about CookieAuthHelper, but I suspect
only the person who wrote it could justify it.  I don't know who wrote
it, so here it is.

I recently hunted down a problem whereby when a visitor without an auth
cookie visited a site that had cookie auth set up to do a challenge
would need to present his credentials twice.  Without fail on both IE
and Mozilla, the first auth attempt would fail.  A direct subsequent
attempt would succeed.

This turned out to be the fault of the cookie auth helper itself,
inasmuch as changing its extractCredentials method with this patch fixed
the problem...

Index: CookieAuthHelper.py
===================================================================
RCS
file: /home/dixonhughes_com/cvs_efr/Products/PluggableAuthService/plugins/CookieAuthHelper.py,v
retrieving revision 1.2
diff -u -r1.2 CookieAuthHelper.py
--- CookieAuthHelper.py 8 Nov 2004 09:11:37 -0000       1.2
+++ CookieAuthHelper.py 14 Nov 2004 03:47:15 -0000
@@ -117,8 +117,8 @@
                 creds['login'] = login
                 creds['password'] = password

-                request.set('__ac_name', '')
-                request.set('__ac_password', '')
+                #request.set('__ac_name', '')
+                #request.set('__ac_password', '')

         if creds:
             creds['remote_host'] = request.get('REMOTE_HOST', '')

The problem was that the request.set puts "__ac_name" and
"__ac_password" (both as blank strings) into the REQUEST.other
dictionary.  I have no idea why this is done.  Subsequently, later in
the request, when the "login" method is called as a result of the
login_form form post, it finds two blank strings, sets the auth cookie
to the base64-encoded value of the two blank strings separated with a
colon in updateCredentials, and redirects to the came_from URL.

The attempted access of the came_from URL of course denies access when
the next request comes in because the credentials are wrong, and
redisplays the login form.  A subsequent submission of the login form
goes through a different codepath (presumably because the auth cookie
exists now), and allows access.

So my question is: the patch fixes the problem, but am I going to break
something for someone else by committing it?  I really have no idea why
you would want to set these items in the request to blank strings during
extractCredentials.  Should the "login" method somehow try to get the
credentials not from the request itself (as it does now) but from the
PAS object, which asks for them in _extractUserIds?

I'm not sure why I have this problem and no one else seems to see it,
either.  It seems like it should happen to everyone.

- C