Angular CORS简单请求使用POST中的Authorization标头触发预检

本文介绍了Angular CORS简单请求使用POST中的Authorization标头触发预检的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

根据文档，对于简单的请求，不应进行预检: developer.mozilla/en/docs/Web/HTTP/Access_control_CORS ).

The preflight is not supposed to happen for simple requests as per the documentation: developer.mozilla/en/docs/Web/HTTP/Access_control_CORS).

如果我不在请求中添加其他"Authorization"标头，则确实是这种情况:

This is indeed the case if I don't put the additional "Authorization" header in the request:

"Content-Type": "application/x-www-form-urlencoded", "Authorization": "Basic _base64_string_"

没有授权"标题:

:authority:www.target :method:POST //<----------------This is correct :path:/oauth2/access_token?client_id=xxx-xxx :scheme:https accept:application/json, text/plain, */* accept-encoding:gzip, deflate, br accept-language:en-US,en;q=0.8,fr;q=0.6 content-length:79 content-type:application/x-www-form-urlencoded//<----------------This is correct origin:source:4200 referer:source:4200/

通过"Authorization"标题，将自动设置OPTIONS方法:

With "Authorization" header, OPTIONS method is automatically set:

:authority:www.target :method:OPTIONS //<----------------This is NOT correct, caused by Authorization header :path:/oauth2/access_token?client_id=xxx-xxx :scheme:https accept:*/* accept-encoding:gzip, deflate, sdch, br accept-language:en-US,en;q=0.8,fr;q=0.6 access-control-request-headers:authorization access-control-request-method:POST origin:source:4200 referer:source:4200/

由于此问题，我无法授权我的应用，服务器响应为:

Because of this issue, I am unable to authorize my app, the server response is :

HTTP method 'OPTIONS' is not allowed. Expected 'POST'

因此，似乎"Authorization"标头触发了CORS中的预检. 任何人都可以对此有所了解吗?

So it seems that the "Authorization" header triggers the preflight in CORS. Can anyone shed some light on this please?

推荐答案

由于此问题，我无法授权我的应用，服务器响应为:

Because of this issue, I am unable to authorize my app, the server response is : HTTP method 'OPTIONS' is not allowed. Expected 'POST'

如果您对发送请求的服务器具有管理员访问权限，则需要将该服务器配置为允许HTTP OPTIONS请求，并使用Access-Control-Allow-Headers和Access-Control-Allow-Methods响应标头来响应它们浏览器需要查看才能允许实际的GET或POST或您要创建的内容(除了Access-Control-Allow-Origin响应标头，浏览器还需要查看实际的请求).

If you have admin access to the server the request is being sent to, then you need to configure that server to allow HTTP OPTIONS requests, and to respond to them with the Access-Control-Allow-Headers and Access-Control-Allow-Methods response headers that browsers need to see in order to allow the actual GET or POST or whatever you’re trying to make (in addition to the Access-Control-Allow-Origin response header browsers need to see for the actual request).

如果您没有对该服务器的管理员访问权限，无法对其进行配置以将启用CORS的响应发送给OPTIONS请求，那么从前端JavaScript代码获取请求以与其配合使用的唯一选择是设置一个CORS代理并通过该请求发出请求. 上的答案；所请求的资源上没有"Access-Control-Allow-Origin"标头".具有操作方法的详细信息.

If you don’t have admin access to that server to configure it to send that CORS-enabled response to OPTIONS requests, then your only option for getting requests from frontend JavaScript code to work with it is to set up a CORS proxy and make the request through that. The answer at "No 'Access-Control-Allow-Origin' header is present on the requested resource" has how-to details.

除此之外，您唯一的其他选择是不从您的前端JavaScript代码发出请求，而是从您自己的后端代码发出请求，从而绕过浏览器施加的跨域限制.

Your only other option beyond that is to not make the request from your frontend JavaScript code but to instead make it from your own backend code instead, which bypasses the cross-origin restrictions that browsers impose).

因此，似乎"Authorization"标头触发了CORS中的预检.谁能对此有所启发?

So it seems that the "Authorization" header triggers the preflight in CORS. Can anyone shed some light on this please?

是的，当您添加Authorization标头时，它不再是简单请求".

Yeah, when you add the Authorization header, that makes it no longer a "simple request".

developer.mozilla/en -US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests 对此进行了说明；它说触发浏览器进行预检的条件之一是:

developer.mozilla/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests explains this; it says that one of the conditions that triggers the browser to do a preflight is:

如果，除了用户代理自动设置的标题(对于 例如Connection，User-Agent或其他任何带有 在提取规范中定义为禁止标头名称" )的名称， 该请求包括除提取的标头之外的所有标头 规范定义为"CORS安全列出的请求标头" ， 如下:

If, apart from the headers set automatically by the user agent (for example, Connection, User-Agent, or any of the other header with a name defined in the Fetch spec as a "forbidden header name"), the request includes any headers other than those which the Fetch spec defines as being a "CORS-safelisted request-header", which are the following: Accept Accept-Language Content-Language Content-Type DPR Downlink Save-Data Viewport-Width Width

Authorization不在该列表中，因此会触发预检.

The Authorization is not in that list, so it triggers a preflight.