[Zope-PAS] Re: CookieAuthHelper.

[Chris McDonough]

I've applied the patch.  Scream if it breaks something for you (although
I can't see how it would).

On Sat, 2004-11-13 at 23:00 -0500, Chris McDonough wrote:
> 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
>