I would like to separate my front-end login from back-end login, but the front-end login will use oAuth-based third-party authentication whereas the back-end will continue to use the WordPress database. Can somebody recommend the best practice to add a separate script for my front-end form to post to, which would still need to use the WordPress framework to log-in authenticated users and create users who successfully authenticate against the third party.

I don't have a problem with any of the coding of the functionality - I'm not a beginner to PHP - but I'm just not sure how, in WordPress, to define a destination to which a form can be posted but that isn't a page or post or any other kind of standard WordPress content. Can I define a route in a plugin to catch a POST request from a form in a widget? I dislike the idea of posting to some kind of /wp-content/plugins/frontend-login.php but if that's the best option, so be it. I'd just like to be sure.

  • I strongly recommend against making direct requests to PHP files in plugins and themes, it isn't necessary to handle requests and opens up a big security hole. For what you're wanting to do it's unneccessary, a rewrite rule, hook, or page template work just fine. However, I don't see any security benefit to what you're trying to do. Anybody who can log into the frontend can use the same details to log into the backend. Once they're logged in on the frontend they don't need to login to the backend they just need to stay logged in then visit it by adding /admin to the homepage URL – Tom J Nowell Oct 2 '20 at 14:42
  • You might even reduce your sites security by increasing the attack surface and breaking lots of assumptions WP and plugins make. If you're using OAuth 3rd parties though then I don't see how the login URL comes into it. Just show users the log in options directly and bypass having to present them on a login PHP file entirely. Like how the login form widget is just a form on the frontend, except this would be a login with X button. How you would implement that tough is extremely specific to that provider, so specific that no generic solution is available, you'd need to ask them – Tom J Nowell Oct 2 '20 at 14:42
  • @TomJNowell - my plan is that people who login via the oAuth route are assigned a role (say "frontend_user") that is denied access to the dashboard, so a frontend user will never have access to the admin area. The same role will be used to grant access to restricted content. After some further research, I think the best flow will be to have the login link for front end users point to the oAuth service login page with the post login redirect being to admin-post.php, then I would handle the login via the admin_post_nopriv hook. Does that make sense? – Ambulare Oct 3 '20 at 13:25
  • @TomJNowell - by the way, the third-party front-end login isn't to increase security, it's a necessity of having a pre-existing oAuth provider containing existing users of another app. I'd now like to give those users access to content on a new site. – Ambulare Oct 3 '20 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.