Chrome Preflight OPTIONS请求在浏览器中返回403/forbidden和不同的标头

ddrv8njm  于 11个月前  发布在  Go
关注(0)|答案(1)|浏览(253)

我目前正在开发一个混合应用程序,它也应该在普通的Web浏览器中工作,稍后通过官方公司域。后端提供了一个REST风格的API,它支持所有类型的事情:获取条目,获取用户等。请求的来源是,至少对于测试和应用程序来说,不是域本身,而是本地主机。
现在导致问题的是使用POSTContent-Type: application/json和JSON主体发布。当在浏览器中运行进行测试时,Chrome执行preflight OPTIONS请求。我理解为什么,这没有问题。不幸的是,请求总是具有403的状态-我认为,das与HTTP状态不对应,但更多的是基于响应本身对Chrome的解释。Chrome还说,HTTP-Control-Allow-Origin头丢失。下面是我可以评估的一些事实:

  • Chrome中的响应确实不包含this和其他一些标头。这绝对没有意义,因为:
  • 同样的OPTIONS请求在Postman(HTTP 200)中也能正常工作
  • Chrome的行为至少在Firefox中是相同的
  • 我从Postman得到的响应包含所有必要的头:

从OPTIONS请求返回的Postman-header:

Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-Auth-Token, Origin, X-Requested-With, Content-Type, Accept, Authorization
Access-Control-Allow-Methods: POST, PATCH, GET, PUT, OPTIONS, DELETE

字符串
有没有人能帮助解释一下是什么原因导致浏览器中的preflight请求失败?为什么OPTIONS响应在浏览器和Postman中不包含相同的头?如果你需要进一步的信息,请告诉我!我没有包含代码,因为OPTIONS请求是由浏览器启动的,而不是由我启动的。
提前感谢你,并致以最好的问候。
编辑:以下是来自Chrome和Postman的完整请求:

Chrome:

General:
Request URL: [HIDDEN]/api2/entries/57734/comments
Request Method: OPTIONS
Status Code: 403 
Remote Address: [HIDDEN]
Referrer Policy: no-referrer-when-downgrade

Response:
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Connection: keep-alive
Content-Length: 20
Date: Tue, 24 Apr 2018 09:18:58 GMT
Expires: 0
Pragma: no-cache
Server: nginx/1.8.0
X-Application-Context: application:production
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Request:
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-DE;q=0.8,en;q=0.7,en-US;q=0.6
Access-Control-Request-Headers: content-type
Access-Control-Request-Method: POST
Cache-Control: no-cache
Connection: keep-alive
Host: [HIDDEN]
Origin: http://localhost:3000
Pragma: no-cache
User-Agent: Mozilla/5.0 (Linux; Android 8.0; Pixel 2 Build/OPD3.170816.012) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Mobile Safari/537.36

Postman Headers:

Access-Control-Allow-Headers: X-Auth-Token, Origin, X-Requested-With, Content-Type, Accept, Authorization
Access-Control-Allow-Methods: POST, PATCH, GET, PUT, OPTIONS, DELETE
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: X-Auth-Token
Access-Control-Max-Age: 1209600
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Connection: keep-alive
Content-Length: 0
Date: Tue, 24 Apr 2018 09:24:04 GMT
Expires: 0
Pragma: no-cache
Server: nginx/1.8.0
Strict-Transport-Security: max-age=31536000
X-Application-Context: application:production
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

uoifb46i

uoifb46i1#

Chrome等浏览器会在发送真实的POST,PUT,.方法之前发送http OPTIONS方法。然后OPTIONS方法会检查以下的origin,method和header是否正确。您需要检查OPTIONS方法的响应header reuest,real-Control-Allow-Origin/Headers/Method(我不确定..确切的标题名称..)如果你有403与OPTIONS方法,你应该检查OPTIONS方法允许在您的服务器!或者您需要检查您的真实的请求(POST,PUT,.)header方法和header是否与OPTIONS方法响应header对应,例如:HTTP-Control-Allow-*!大多数情况下,这是因为您的自定义header!您需要添加http OPTIONS响应header,HTTP-Control-Allow-header:您的自定义头名称!
希望对你有帮助

相关问题