Record that a Cors cross-domain pit has been blocked by Cors policy: Request header field authorizatio

Cause: The delete user button failed to call properly after @click attribute was written.

The first suspicion is that the back-end interface is not written correctly. A delete operation is then performed using the ApiPost:

The backend API was found to be fine.

The second step is to suspect that AXIOS performed the DELETE request incorrectly. the

const res = await this.$http.delete(user/${id})

The RES prints out to find a prompt: “No token”.

Okay, find the Axios request interceptor configuration, In the main. Js add configuration axios. Interceptors. Request. Use (config = > {config. Headers. Authorization = Bearer ${window. The sessionStorage. The getItem (‘ token ‘)} return config}) to add a key to delete a message “Authorization” first, The value for “Bearer” token >”

The user list cannot be loaded, and no data is displayed. Blocked by CORS policy: Request header field authorization is not allowed by Access-Control-Allow-Headers in preflight response.

It seems that the BACKGROUND Cors middleware does not allow authorization to pass, so it is added in the Cors middleware

Problem solved.

But that’s not all. The middleware is gin-contrib/ Cors provided by Gin. What do the AllowHeader and ExposeHeader fields in the figure above represent?

AllowHeader corresponds to access-Control-allow-headers in the pre-check request, indicating in MDN:

Access-control-allow-headers Used in a Preflight request to list the Headers that will appear in the Access-Control-request-headers field of a formal request.

That is, the Authorization head is not allowed to appear in the formal request message unless it is in the AllowHeader.

• This field is used for the front -> back – end.

while

Response Headers Access-Control-expose-headers lists which Headers can be exposed externally as part of the response.

• This field is used by the back -> front – end.