Separate frontend and backend

[pshah-allegion]

Checklist

• I have looked into the Readme and the documentation, and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

We don't want Auth0 to impact backend logins, we would like to implement it only for the frontend.
I'm using version 5.2.1 and also tried to extend it using wpAuth0 SDK as mentioned int the documentation. But it didn't work.

Reproduction

1. Installed necessary composer dependencies and configured plugin backend
2. Backend redirects to Auth0 login page, but it's preferable to keep it a normal WP backend login page.
3. We tried extending using wpAuth0 SDK on mu-plugins, but it didn't work.

Additional context

No response

wp-auth0 version

5.3

WordPress version

6.8

PHP version

8.2

[kishore7snehil]

Hi @pshah-allegion 👋

Thanks for the opening this issue.
By default, every WordPress login attempt (including /wp‑admin) is routed through Auth0. A couple thoughts:

1. Can you share your mu‑plugin snippet?
   If you paste the small code you added , I can help troubleshoot why it didn’t fire especially around hook order or syntax issues.

2. “Frontend‑Only” mode suggestion
   As you noted, v5.x doesn’t natively distinguish front‑end vs. admin logins. You could add your own toggle and logic:

   • Write a helper—e.g. function is_admin_request(): bool—that returns true when is_admin() is true, or when $_SERVER['REQUEST_URI'] or $_GET['redirect_to'] point to /wp-admin or wp-login.php.

   • In src/Actions/Configuration.php, introduce a new checkbox (“Frontend‑Only Mode” or “Exclude Admin Login”).

   • In src/Plugin.php’s isEnabled() (or wherever the Auth0 redirect filter is applied), wrap the filter registration in a conditional:

      if ( $this->options->get('frontend_only') && is_admin_request() ) {
         return false;  // skip Auth0 redirect on admin pages
       }
       return true;
       ```
     

Feel free to share your mu‑plugin code and any php/js errors you’re seeing. Once I can see exactly what you tried, I can help you refine . Let me know!

[pshah-allegion]

Hi @kishore7snehil,

Thanks for the information.

1. I tried multiple things. Here's the example of one of them, please have a look:
   add_action( 'init', function() { if ( strpos( $_SERVER['REQUEST_URI'], 'wp-login.php' ) !== false && ! isset( $_GET['auth0'] ) ) { remove_all_actions( 'login_init' ); } });

2. “Frontend‑Only” mode suggestion

For the suggested solutions, I'll need to make changes in the plugin files for this, right? I was wondering if in case of any future updates, it might become an issue?

• In src/Actions/Configuration.php, introduce a new checkbox (“Frontend‑Only Mode” or “Exclude Admin Login”).
• In src/Plugin.php’s isEnabled() (or wherever the Auth0 redirect filter is applied), wrap the filter registration in a conditional:

[kishore7snehil]

Hi @pshah-allegion,

Thanks for the follow-up question!

Before I dive into the solution approach, I wanted to check: are you still experiencing this issue, or have you been able to resolve it on your end? If you've found a working solution, I'd love to hear what approach you took!

If you're still working on this, here's my take on your concern about future updates:

Regarding modifying plugin files directly: You're absolutely right to be cautious. Any changes made directly to the plugin files (in src/Actions/Configuration.php or src/Plugin.php) would indeed be overwritten when the plugin updates.

The recommended approach for your specific use case would be to implement this as a custom mu-plugin (must-use plugin) in your WordPress installation. This way:

• Your customizations remain separate from the core plugin
• Updates won't affect your custom logic
• You have full control to tailor it to your exact requirements

Why not add this to the core plugin? While I understand this is important for your use case, adding it as a core feature requires us to:

• Consider how it would work across different WordPress configurations and hosting environments
• Ensure it doesn't introduce security vulnerabilities or break existing setups
• Handle various edge cases (REST API requests, AJAX calls, custom login pages, etc.)
• Provide proper documentation and support for all users

Since this is a fairly specific requirement that may not apply to all users, the mu-plugin approach gives you the flexibility you need without the complexity of generalizing it for everyone.

If you're still working on this, I'm happy to point you in the right direction on how to structure a mu-plugin solution that hooks into the right WordPress actions to achieve what you need. Just let me know!

[pshah-allegion]

@kishore7snehil I did a POC with the Auth0 PHP SDK, but it would be preferable to also have an alternative solution that's made specifically for WordPress.