java - Problem with separating verification code from front to back end

Question

premise

Suppose I have an interface for obtaining verification codes. It is under https://api.b.com/captcha.

My imagined way of refreshing the verification code

In my imagination, the verification code refresh function is implemented by adding a timestamp after the url, for example, changing the url to something like this

https://api.b.com/captcha?149...

Traditional method of verifying verification code

The traditional verification code should be mainly done through the session. The front end will record a session id in the cookie.

The backend will also record this session id and its corresponding verification code in redis.

The front end has a function of clicking the verification code to refresh. Each time you click, a new verification code will be generated, and the value of the verification code corresponding to the session ID will be updated in redis every time.

The verification method is completed by querying whether the session id value in redis is consistent with the front-end value.

Problems currently encountered

Now, I am working on a project that separates the front and back ends.

Then there is a cookie cross-domain problem that I don’t know how to solve.

The scenario is as follows: the front-end project is under the domain name of www.a.com, and the back-end project is under the domain name of api.b.com.

The front-end and back-end are under different domain names (in fact, it is also possible to put the two projects under the same domain name, but this is not done for learning purposes), so the cookie cannot be shared. In other words, I get The session id is no longer available. Then the traditional method seems to be no longer possible.

PS: The front-end server will use nginx, and the back-end will use spring-boot.

my thoughts

Idea 1

I want to generate a simple token. The token only contains a uuid, which is used to identify the user. I compare the uuid of this toekn with the uuid in redis to determine whether the value of the verification code is correct. So I will return a result like this

{
   image : base64转码后的图片,
   token : uuid
}

As for why we send base64 transcoded pictures, it is mainly because the front-end img tag supports base64. It's no problem to display this directly (it's not a project that doesn't take ancient browsers into consideration).

But it doesn’t seem very reasonable to do it this way. Because in this way, when you access the address of the verification code, you will not be able to see the picture of the verification code. It is inconvenient to debug and view the verification code style. In fact, it is not particularly inconvenient. It is just that I have to write a js to set the src of the img. It feels quite stupid.

Idea 2

Put the token in the header of the response. js can read the contents of the response header. Then the picture of the verification code can also be displayed directly through the address. But damn, it also feels stupid. Because I can't use the way I imagined to refresh the verification code. Simply add a timestamp later and modify it.

Three ideas

I don’t care about the verification code. Let the front-end server do this. When logging in, verify the verification code on the front-end server. Then my back-end only verifies whether the account password is correct and returns a token. Just bring the token every time you access other APIs.

---

I really can’t think of how to do it, and I can’t find any relevant information (maybe there is something wrong with my search method), so I’m asking for your help....

I checked carefully and this problem should be a single sign-on problem, right?

Answer 1

What you have to solve is the problem of carrying cookies across domains. First, make sure you are using cors technology across domains. cors can send identity credentials based on HTTP cookies and HTTP authentication information. Cookies are sent to the server by setting the withCredentials flag of XMLHttpRequest to true.

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/credentialed-content/';
    
function callOtherDomain(){
  if(invocation) {
    invocation.open('GET', url, true);
    invocation.withCredentials = true;
    invocation.onreadystatechange = handler;
    invocation.send(); 
  }
}

In addition to adding withCredential to the front-end request, the server's response header also needs to add Access-Control-Allow-Credentials: true. In addition, the response header cannot set the value of Access-Control-Allow-Origin to "*" and must set it to the specific source http://foo.example.