Prevent plugin sending users to WP backend

Any update on this please?? I’ve hacked the file to do what i need and I’m looking to override the file permanently. Maybe you could fix things for future users of this plugin and the many negative feedback users who have pointed out similar issues too.

Thank you for using our plugin @trutherone

Sorry for the late reply. The last few days have been very hectic. I am not sure what negative feedback you are referring to. Can you please share some links / reference?

In regards to your problem; let’s start with the login process: if you do not use the plugin and users log in, where are they redirected to?

The reason I am this because the plugin is not responsible for nor does it change where the users are redirected to after any interaction with any of the 2FA pages, or if they should have access to the backend or not. The plugin simply follows what is already configured in WordPress. If you do not want your users to access the backend, then you have to:

1.a. Create some sort of portal or pages which users can access once logged in
1.b. Use a “post-login redirect” plugin, or the “redirect_to” filter in WordPress to override the redirection URL.
1.c. Then you can use the front-end 2FA page in WP 2FA so users do not have to access the backend.

For example this works perfectly with plugins like WooCommerce or Easy Digital Downloads. Both plugins create a user portal, and users log in to the portal, access the portal, and configure 2FA via the portal. It is WooCommerce or EDD in this cased which control where the user is redirected to after logging in, or what the user can access or not.

As for the “nulled href”, there is no nulled href in class-login.php. The “#” has a JS attached to it and by removing it you will certainly break other things. That is used by the plugin so it follows the already configured redirection rules from WordPress, which usually come from “redirect_to” parameter, which comes from the WordPress login itself, and which is executed before our plugin actually kicks in.

So the plugin is simply adding an “extra step” during an existing login process. It does not interfere, control or modify the flow of that user journey.

I hope the above helps and you manage to solve your issue. Should you have any further questions, please do not hesitate to ask.

Have a great day.

All well and good but thats not what happens. I have a custom front-end UI for users, so the wp dashboard and admin section is out of bounds for all users except for me. See the screenshots of your settings page were ive chosen to block users who do not want to setup 2fa yet (it doesn’t work in use – the user is just directed to the wordpress dashboard irrespective of what i chose in the setting page.

If i’m right in thinking the line: $_REQUEST[‘redirect_to’], will always send users to the default location (wp_admin) yes?? I changed the line in, class-login.php, line 218 from admin_url() to home_url – that fixes the problem. Unless you put an option in the settings page to allow us to specify where users are redirected after choosing NOT to setup 2fa yet then your code assumes it should always redirect them to the dashboard! Thats only ok if you are allows dashboard access for your users; otherwise it ruins your front-end only functionality!! – Look at the screen shots.

Clicking the “I’ll do it later” button (this one) – https://prnt.sc/0TbsgvzL7KFk

The plugins 2fa setup page – https://prnt.sc/LSmby4DfhIHG

Your code line in class-login.php (line 218) – https://prnt.sc/VHbVRXTmxncI

We changed to – https://prnt.sc/vgGcyFCrvng_

Thank you for providing additional details about your setup @trutherone

By the way, we strongly recommend against making direct modifications to the plugin’s code. Altering the core files can impact the plugin’s stability and make it challenging for us to provide you support. Instead, use WordPress hooks and filters for customizations. For instance, you can use the admin_url hook within WordPress Core get_admin_url function to create custom logic. This allows you to check a user’s role and define their redirection destination accordingly.

Regarding your specific query: the $_REQUEST[‘redirect_to’] parameter does not send users to /wp-admin/. Instead, it redirects users to their designated “admin area.” Here’s an example to clarify this:

On a WooCommerce site, users with the Customer role do not have access to /wp-admin/. Instead, their admin area is the /my-account/ page.

If you install WP 2FA alongside WooCommerce, when a Customer logs in and clicks “I’ll do it later” they are redirected to /my-account/, and not /wp-admin. This behavior is controlled by WooCommerce filters, which define the user’s admin area.

WP 2FA does not interfere with these redirection rules. It temporarily pauses the login process to display the 2FA prompt. Once the user interacts with the prompt (e.g., clicking “I’ll do it later”), control returns to WordPress, which handles the redirection based on the user’s role and other filters.

From what you’ve described, it seems the issue may be related to how your custom portal is configured. Specifically, the “admin area” for your users may not be properly defined. So this is not a WP 2FA plugin issue.

I hope this explanation helps clarify things and you update the review you posted.

If you have further questions feel free to reach out!

Your explanation is fine but you do not address the use-case for shortcodes. The way we’ve changed the code is fine for users willing to dig into WordPress code; most users won’t know how to do that. So the point i’m making still stands. When the 2fa settings which i screenshotted in the last thread is chosen there should be a textbox shown so we can specify a page to redirect the user to if they are not allowed to access wp-admin, i.e. when they are blocked. You’ve done this further down the settings page so it just needs another inputbox to cater for shortcode admins with custom front-end admin pages.

After more testing i see that i should be more specific – when you set the grace period to 5 days (like we have) then until the 5 days expires the user should still not access the backend which is what the plugin does; default. After the 5 days has expired the user is landed on the homepage which is good i.e. they aren’t directed to wp-admin so the ‘Blocking’ option works ok. In short its during the grace period that the problem occurs. Its probably an edge-case because the majority of your users probably dont use the shortcode feature. Please just try it and you’ll see what we’re highlighting; without the small hack we’ve implemented we can’t use use it and we’ve wasted a lot of time already on this in the project.

Thanks