Philippe Signoret

That change doesn’t really help in this situation, because my plugin does run at wp-login.php.

No, the plugin does go through wp-login.php. So your plugin is still getting invoked (and blocking the sign-in from completing).

I think it’s a fair expectation on your part, and on the part of others filtering authenticate, that the filter will be invoked during a forms-based sign-in. So, I’ve done a bit of re-factoring and moved my plugin’s logic to run earlier, during login_init.

If the user successfully signs in with Azure AD, the WordPress auth cookie gets set, and the user is redirected immediately on to where they should go (these steps of setting the cookie and redirecting were handled by Core when I used authenticate, so I had to re-write them in my plugin). This effectively avoids login-recaptcha ever getting an opportunity to block the sign-in. If, however, the user attempts to do regular forms-based sign in, my plugin does nothing and allows yours to do it’s thing.

I haven’t done a lot of testing yet, but I’ve pushed an experimental version of this to the experimental-no-authenticate branch of my plugin, in case anyone wants to test.

• This reply was modified 6 years, 11 months ago by Philippe Signoret.

I think the main disconnect here is that what you describe is still very strongly tied to the idea of modifying, or somehow playing into, the existing username/password WordPress form.

Azure AD SSO (and other similar plugins) are for folks who want to (sometimes) skip the WordPress authentication process, delegating the process of authenticating the user to a separate system. This separate system (Azure AD, in this case) is not under the control of the customer, or the plugin, and that’s the whole point.

Ultimately, customers will fall into one of two categories:

• Skip the reCaptcha for users who signed in with Azure AD, and enforce the reCaptcha for users using forms-based sign-in.
• Enforce the reCaptcha in addition to either forms-based sign-in or and Azure AD sign-in.

I believe the majority of customers will prefer the former.

In any case, I’ll look into this some more (and have a look at what some other related plugins are doing in this situation), and propose something.

@robertpeake I’m the author of the Azure AD SSO plugin. I’ve had a look at this plugin, and I see how the fact that the Azure AD SSO plugin filters authenticate is problematic for your plugin (and any plugin which is also filtering authenticate and requires user interaction).

What would you suggest that is the “standard WordPress authentication approach”?

Here’s what I’m considering:

1. Instead of filtering authenticate, hook into init (or perhaps something more specific to wp-login.php) for initiating the sign-in and processing the response.
2. On successfully matching the signed-in user (according to Azure AD) to a WordPress user, use wp_set_current_user(...) and wp_set_auth_cookie(...) to make it official in WordPress.
3. Redirect on to the right place.

(If you have any reference for what the most correct approach is, I’d be delighted to read up on that.)

And, this is besides the point, but just so we’re all on the same page: the Azure AD SSO plugin itself doesn’t implement a custom form for login. It triggers a standard OpenID Connect sign-in request to Azure AD, and processes the response, matches up the authenticated user to a WordPress user, and makes the user “be signed in” in WordPress.

• This reply was modified 6 years, 11 months ago by Philippe Signoret.