authenticate filter in WP 2.8

  • I have an LDAP authentication plugin that currently relies on replacing wp_authenticate(). I only recently noticed the new “authenticate” filter as my plugin has continued to work after the transition from 2.7.x to 2.8.x.

    I have a question about this filter that I am having troubles answering. It seems that the filters are applied in order of priority. For example, authenticating with username/password in WP is set as a priority 20 while using a cookie is set at 30. I assume my integration should use 10 as that seems to be the default for added functionality.

    I also grasp the idea of deferring to higher priority plugins: if ( is_a($user, ‘WP_User’) ) { return $user; }

    However, when it comes to authentication a chain of multiple authentication methods which can say yea/nay to a username/password combination can be unnecessarily insecure. For instance, if my plugin attempts to log the user in with LDAP and fails, it should fail permanently, not give the same credentials a shot at the local database.

    This widens the effective attack target and essentially creates two passwords (or more) that can access one username’s account.

    In my current architecture I have handled this by rewriting wp_authenticate as I see fit (ie, “all willy nilly). I allow users to specify a login security mode that either permits failed logins to hit the wp system for another try or fails permanently (default).

    However, using filters it seems that it will simply keep moving down the chain regardless of what I do. Is this true? Am I missing something obvious?

    I have not done a tremendous amount of testing yet as this requires a significant rewrite. I’m hoping someone else can explain how this is *supposed* to work before I spend a few days doing a rewrite. ??

    Thanks in advance,
    Clif

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter Clifton Griffin

    (@clifgriffin)

    No input? None?

    if ldap auth fails, then return a WP_Error instead of just null. The built-in ‘authenticate’ implementations will not try to authenticate the user against the wordpress user database, though there is nothing stopping some other plugin from doing something.

    err.. scratch that, I don’t think they will bail if a WP_Error is returned. hmph.

    I’m not sure that it would make sense to have the default implementations bail out if they are passed a WP_Error. Sometimes you might want authentication to fail over to a secondary method, sometimes not. Perhaps the best thing to do in your case is to actually remove the default password implementation from the authenticate hook:

    remove_action(‘authenticate’, ‘wp_authenticate_username_password’, 20);

    You’d want to do that in addition to returning a WP_Error.

    Will,

    I’m trying to prevent registered users who have not activated their account. I’ve already implemented creating a user with a md5 unique id in the usermeta table (attached to their user id). I’m basically trying to check for that “activation_key’ value in the usermeta table on login, if a value exists, I want to prevent the login from occurring.

    The authenticate filter seems to be exactly what I need but after modifying it and placing it into my functions.php file, it doesn’t seem to work! Login occurs per usual.

    Would I need to edit the pluggable.php file, and then apply filter in my functions.php file?

    Thread Starter Clifton Griffin

    (@clifgriffin)

    wnnoris,

    I realize it’s been 8 months since you posted, but I was revisiting this issue and stumbled upon my old post and your response.

    I think removing the filter is a perfect solution.

    Thanks,
    Clif

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘authenticate filter in WP 2.8’ is closed to new replies.