conflicts with dav.module HTTP authentication [#307758]

I realize that this is a bit of an edge case, but please bear with me. This happens on 6.x-1.0, but I've checked the diff to 6.x-1.1 and it still happens.

In a nutshell, the dav.module implements its own 401 header (using a PEAR WebDAV library) to authenticate users at /dav in a manner almost identical to your module.

But with a weight of -50, httpauth.module gets in there first and, in our installations, which are based off of LDAP authentication, fails login since it calls user_authenticate() directly.

All of that aside, it occurs to me that httpauth.module's implementation of hook_boot() should not only return early if the authentication isn't enabled (as it does now), but also if the path being requested isn't in the httpauth_pages list. There seems to me no reason why it should be trying to authenticate the user if the page isn't one for which the site admin wants HTTP authentication to be handled by the module.

For that matter, httpauth_pages doesn't seem to be used at all. If a patch for that is all that's required, I'm glad to provide it.

Sorry for the long-windedness, but that's the nature of this problem.

Comments

Comment #1

decafdennis commented 13 September 2008 at 13:48

HTTP authentication is enabled for all pages. The httpauth_pages option is only for specifying on which pages the module should ask for HTTP authentication by sending a WWW-Authenticate header upon access denied.

Are you saying this problem could be fixed by making sure dav.module has a lower weight than httpauth.module?

Comment #2

Justin Miller

he/him/his

English

Portland, OR

commented 16 September 2008 at 22:32

Thanks for your reply and attention to this.

I'm not sure I understand what you're saying about 'all pages'. If the module doesn't ask (i.e., force a 401 header), then how is the auth enabled? To my knowledge, the client wouldn't provide the auth info unless prompted with a 401, so the normal Drupal login would be the only thing in effect.

Regarding the module weights, that won't help, as DAV is request-based, not hook_init()- or hook_boot()-based like your module. A normal menu callback is registered and when that path (/dav) is hit, a particular Drupal callback function spawns the DAV server, which handles the request (and authentication) via an implementation of PEAR HTTP_WebDAV_Server. Any earlier in the process and hook_init() and hook_boot() will still get called first.

Comment #3

Justin Miller

he/him/his

English

Portland, OR

commented 16 September 2008 at 23:16

So to clarify my original issue, the weight is apparently not relevant to all of this. The main issue is that your hook_boot() is called when a user and password are provided (e.g., in response to a previous 401) and then user_authenticate() is called before DAV has a chance to authenticate things itself.

Process:

1) User visits /dav.
2) DAV module sends back a 401 request for authorization.
3) Client provides the credentials.
4) HTTP Auth module's hook_boot() sees credentials and calls user_authenticate(), failing for installations using LDAP.
5) Go to step 3 and repeat ad infinitum.

If you can help me understand why hook_boot() should respond to these request, in principle, or help me figure out a clean way to have your module ignore requests under variable_get(DAV_ROOT, 'dav'), that would be ideal. Perhaps something like this?

    // Abort if the user with the provided credentials is already logged in or if authentication should be passed to dav.module.
    if (($user->uid && strcasecmp($user->name, $name) == 0) || (module_exists('dav') && arg(0) == variable_get(DAV_ROOT, 'dav'))) {
      return;
    }

Comment #4

miglius commented 17 September 2008 at 07:09

I think the patch http://drupal.org/node/309428 could solve this issue. That patch allows replacement of the authentication function used to authenticate users. For the latest LDAP dev version you could use a ldapauth_authenticate() function as a replacement.