我的网站有两个https服务器。一个(前端)提供由静态页面组成的UI。另一个(后端)提供微服务。他们俩都碰巧使用相同的(测试)X509证书来识别自己。单独地,我可以通过https连接到它们,需要客户端证书“tester”。
到目前为止,我们通过nginx设置隐藏了CORS问题,这使得前端和后端看起来是相同的Origin。我已经为所有请求实现了标题'Access-Control-Allow-Origin','Access-Control-Allow-Credentials';使用方法,预检检查请求的标题(OPTIONS)。
在Chrome中,像这样的跨站点工作得很好。我可以看到前端URL和后端URL是不同的站点。我看到OPTIONS请求是在发出后端请求之前发出的。
即使Chrome似乎不需要它,我确实找到了用于执行请求的xmlhttprequest对象并在其上执行了xhr.withCredentials = true
,因为这似乎是fetch。当js获得"credentials":"include"
时,它会在引擎盖下进行。我注意到我可能需要使用xhr.setRequestHeader
函数来使Firefox开心。
这里是否有人将CORS与2路SSL证书结合使用,并且遇到了这个Firefox问题并将其修复了。我怀疑它不是服务器端修复,而是客户端需要做的事情。
答案 0 :(得分:2)
我还没有使用客户端证书对此进行测试,但我似乎记得,如果将Access-Control-Allow-Origin
设置为*
通配符而不是实际域,Firefox将不会发送凭据。请参阅MDN上的this page。
此外,Firefox向服务器发送CORS请求也存在问题,该服务器希望在TLS握手中呈现客户端证书。基本上,Firefox不会在预检期间发送证书,造成鸡和鸡蛋问题。请参阅有关bugzilla的this bug。
答案 1 :(得分:0)
使用带有凭据(基本身份验证,cookie,客户端证书等)的CORS时:
Access-Control-Allow-Credentials
必须为true
Access-Control-Allow-Origin
一定不能成为*
Access-Control-Allow-Origin
不能是多值的(既不是重复的也不是逗号分隔的)Access-Control-Allow-Origin
必须设置为与请求Origin
标头中的值完全相同才能使请求正常工作(以这种方式硬编码或通过允许值的白名单)注意:对于Access-Control-Allow-Origin
,您可能要考虑允许值null
,因为重定向链(例如通常用于OAuth的重定向链)会导致来自请求的Origin
值浏览器。