Feature: Disable built-in WordPress login / password reset / signup

[zabalajka]

All Submissions:

• Have you followed the plugin Contributing guideline?
• Does your code follow the WordPress' coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

Adds a setting Disable WordPress login and signup forms when all user management should be delegated to Identity Provider and it shouldn't be possible to login from within WordPress. Details are summarized in #477

When enabled:

• login (with username/password) (by default in wp-login.php) is disabled
  • other plugins/themes may move the login form elsewhere; this doesn't affect OIDC and the login will be disabled regardless
• signup/registration (by default in wp-login.php?action=register) is disabled; when user exists only within Identity Provider but not in WordPress, setting Create user if they do not exist is still applied (no change here)
• password reset (by default in wp-login.php?action=lostpassword) is disabled
• login form is hidden in wp-login.php to prevent user confusion

Setting OIDC_DISABLE_WP_LOGIN_AND_SIGNUP is introduced.

Closes #477.

How to test the changes in this Pull Request:

1. Configure OIDC as usual.
2. Go to wp-login.php. It is possible to login with WordPress username/password.
3. Change OIDC setting Disable WordPress login and signup forms to true.
4. Go again to wp-login.php. The login form is not available anymore. Also links to Signup and Password reset and removed.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully run tests with your changes locally?

Changelog entry

Added option to disable built-in WordPress login, signup and password reset functionality.

[zabalajka]

[ ] Have you written new tests for your changes, as applicable?

How / where can this be done? I didn't find anything related in the repo, am I missing something?

[ ] Have you successfully run tests with your changes locally?

Which tasks should be run to perform this? There are several tasks in package.json and I am unsure what to do.

[timnolte]

@zabalajka

[ ] Have you written new tests for your changes, as applicable?

How / where can this be done? I didn't find anything related in the repo, am I missing something?

[ ] Have you successfully run tests with your changes locally?

Which tasks should be run to perform this? There are several tasks in package.json and I am unsure what to do.

So, we haven't developed the test suite yet so that first item can be ignored. As for testing locally it just means that regards to what has been described for the testing instructions have you performed these steps locally as well.

[zabalajka]

Thanks @timnolte , it makes sense now.

[timnolte]

Just noting that most of the plugin settings can be configured via constants. This means that changing the configuration is as simple as updating your wp-config.php or however you may define your WordPress constants(e.g. a .env file). I actually don't think it's appropriate, or secure, to allow plugin configuration to be bypassed by simple URL parameters.

[miguel-rn]

Just noting that most of the plugin settings can be configured via constants. This means that changing the configuration is as simple as updating your wp-config.php or however you may define your WordPress constants(e.g. a .env file). I actually don't think it's appropriate, or secure, to allow plugin configuration to be bypassed by simple URL parameters.

Yes, I had the same thinking which is why I deleted my comment a mere moment after posting it. Didn't think anyone could read it haha.

[timnolte]

@miguel-rn I am not clear why you aren't configuring the plugin to use Auto instead of Button. It seems like the Auto setting should already be taking care of all of this.

[rasos]

Hiding the password reset / signup field would make much sense not oly for the Auto SSO, but also for the OpenID connect button on login form mode. We keep the login form as a second door, most users use a login link with the [openid_connect_generic_login_button] on the start screen.

[gg-gg-gg-gg]

Hello! I was curious if this PR is still a WIP, we were hoping to use this plugin but have a security requirement all methods of authentication are disabled outside of OIDC.

[timnolte]

@gg-gg-gg-gg have you tested with using the Auto mode for login? This already effectively makes it required to use OIDC as the only means to login.

[gg-gg-gg-gg]

Yes, the way I tested was

1. Disabled the plugin
2. Made a login request using username & password with curl
3. Copy the cookies that it set and ensure they're valid
4. Enabled the plugin in auto mode
5. Repeated the login request
6. The response still sets valid cookies