Access to XMLHttpRequest at ‘http://abc.com‘ from origin ‘http://xxx.com‘ has been blocked by CORS p

Access to XMLHttpRequest at 'http://abc.com' from origin 'http://xxx.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

今天同事改一个老项目的请求配置，本地改完没问题，部署之后报跨域问题，搞了半天没解决，帮忙看了一下，错误如↑

看了一下错误提示，上面说这个错误是由于浏览器的跨域资源共享（CORS）策略引起的。浏览器默认情况下限制了从一个源（origin）向另一个源发送跨域请求。

根据错误消息，咱们的请求是从 `http://abc.com` 发起的，而目标地址是 `http://xxx.com`。由于这两个域名不同，浏览器会执行预检请求（preflight request）来检查服务器是否允许跨域请求。

预检请求的目的是检查服务器是否允许实际请求（例如 GET、POST）的跨域访问。服务器需要在响应的头部中包含一些特定的信息，以便浏览器确认是否允许跨域访问。

错误消息中提到了一个特定的问题，即响应头部中的 `Access-Control-Allow-Origin` 字段的值不能为通配符 '*'，当请求的凭据模式为 'include' 时。这意味着你的服务器需要设置具体的允许跨域访问的域名，而不是使用通配符。而这个问题是由XMLHttpRequest的withCredentials属性控制的

一般为了解决这个问题，咱们可以在服务器端进行配置，确保响应头部中的 `Access-Control-Allow-Origin` 字段的值是请求源的域名，而不是通配符。例如，你可以将该字段设置为 `http://abc.com`。

另外，还需要确保服务器在预检请求的响应中包含其他必要的头部字段，例如 `Access-Control-Allow-Methods` 和 `Access-Control-Allow-Headers`，以指定允许的请求方法和头部信息。

但咱们是多个项目用一个接口，显然这个方式不合适

这个时候，我们看一下这个incloude模式是什么意思？咱们的代码为什么会是这个模式？如果不设置成这个模式，是不是就可以了？查找资料后总结如下：

当请求的凭据模式为 'include' 时，意味着在发送跨域请求时，浏览器会在请求中包含凭据信息，例如身份验证凭证（如 cookies）或 HTTP 认证头部。这通常用于需要在跨域请求中传递用户凭据的情况，例如进行身份验证或会话管理。

在默认情况下，浏览器在跨域请求中不会发送凭据信息。但是，如果你的代码中设置了请求的凭据模式为 'include'，例如通过将 XMLHttpRequest 对象的 withCredentials 属性设置为 true，那么浏览器会在发送跨域请求时包含凭据信息。

当请求的凭据模式为 'include' 时，CORS 策略要求服务器的响应头部中的 Access-Control-Allow-Origin 字段的值不能是通配符 '*'，而是必须是实际请求的源域名。这是为了确保凭据信息不会被恶意网站获取到。

这里看到了withCredentials关键词，同时上面报错也提到了withCredentials

回项目里搜withCredentials，果然，在封装的http请求里，看到了

$https.defaults.withCredentials = true;

注释掉，重新部署，问题解决啦  ^_^

完成后，查一下withCredentials是干啥的，因为是老项目，也不知道有没有用。

`withCredentials` 属性是 `XMLHttpRequest` 对象的一个属性，用于指定在发送跨域请求时是否包含凭据信息（如 cookies、HTTP 认证头部）。

当 `withCredentials` 属性设置为 `true` 时，浏览器会在发送跨域请求时包含凭据信息。这可以用于以下场景：

1. 跨域身份验证：当你的应用程序需要在跨域请求中传递用户凭据（如 cookies）以进行身份验证时，你可以将 `withCredentials` 设置为 `true`。这样，在发送跨域请求时，浏览器会自动包含用户的身份验证凭据，使服务器能够验证用户并提供相应的响应。

2. 跨域会话管理：如果你的应用程序需要在跨域请求中维护会话状态，你可以使用 `withCredentials` 属性。通过在跨域请求中包含会话凭据，服务器可以识别用户的会话并保持会话状态的连续性。

需要注意的是，使用 `withCredentials` 属性需要服务器支持接收和处理包含凭据信息的跨域请求。服务器需要正确配置 CORS 响应头部，允许接收跨域请求的凭据信息。否则，在发送带有凭据信息的跨域请求时，浏览器会拒绝该请求。

总结来说，`withCredentials` 属性的作用是允许在跨域请求中发送凭据信息，常用于跨域身份验证和跨域会话管理的场景。但使用时需要确保服务器端正确配置和处理跨域请求的凭据信息。

而咱们这个问题就是因为，服务端Access-Control-Allow-Origin设置为“*”，咱们withCredentials又设置为true导致的冲突导致的。