Q1. How can we do this login event? Can we login via API or do we need something different? I’m asking because I’ve seen ways to log in with a cookie.
The WP REST API provides no session management functionality. There is no way to login, register, or logout via the REST API.
If it did, the registration endpoint in your question would be unnecessary.
Plugins might exist that provide session management, but doing this will require 100% custom code.
If it helps, this is the automatic API discovery process for the REST API that reveals the authentication methods it exposes:
https://developer.wordpress.org/rest-api/using-the-rest-api/discovery/#authentication-discovery
You may find with 3rd party authentication plugins that the ability to login via the API and create new authentication sessions purely via the API might be possible.
Q2. When it gets Ok result from API, it will return to WordPress site and log in. How can we make this turn?
You would need to create an entirely new endpoint to do this. Software such as Softaculous has an advantage the REST API does not because it can reach behind the scenes and do things directly to the database, run PHP scripts directly with priviledged access, or WP CLI commands such as wp user create etc and do things that can’t normally be done.
A common method on enterprise hosting is to do this via a WP CLI command using internal mechanisms that aren’t reachable via a browser or the open web, such as queued tasks or internal proprietary cron jobs. Others use custom REST API endpoints that create temporary users and then set up credentials and custom filters to bypass what the site normally does ( you would not want to do this as it has major security implications and is not scalable, these systems are built with a lone hosting support/maintenance agent in mind, not for regular use ).
These usually create temporary back doors that self-close, with mechanisms that rely on temporary tokens etc
Note that if we ignore all of this, the code in the question is insecure:
- there is no rate limiting
- it does not check if a user already exists
- but it does return the error object, allowing an attacker to fire of repeated requests for usernames to see which ones generate user already exists errors
- this also works for emails!!
- although emails are sanitised, there is nothing checking that they are emails, and the endpoint will happily accept
"I'm not an email"and pass it to$email - the endpoint bypasses the validation/verification step to confirm the user does indeed own that email. Anybody can sign up with anybody’s email, I could sign up with your email! And there’s nothing anybody could do about it. This has major legal and regulatory consequences, you should consult a lawyer with expertise in this area before continuing.
- There are no protections for password strength and integrity in the API, this endpoint bypasses those entirely.
.would be a valid password.- it may even be possible to use a blank password which would make it impossible for the user to login
I suspect you’ve used this answer on Stack Overflow to create the endpoint, which has its own issues, but then removed half of the protections it uses such as username_exits etc: