首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

为什么在服务端设置Access-Control-Allow-Origin后仍然出现跨域错误?

在服务端设置Access-Control-Allow-Origin后仍然出现跨域错误可能是由于以下几个原因:

  1. 请求头中的其他跨域相关字段未设置:除了设置Access-Control-Allow-Origin字段,还需要设置其他跨域相关的请求头字段,如Access-Control-Allow-Methods、Access-Control-Allow-Headers等。这些字段需要根据实际情况进行设置,以满足跨域请求的要求。
  2. 请求方法不符合预检请求规范:对于某些复杂的跨域请求,浏览器会先发送一个预检请求(OPTIONS请求),以确定服务器是否允许实际的跨域请求。在预检请求的响应中,除了设置Access-Control-Allow-Origin字段,还需要设置Access-Control-Allow-Methods和Access-Control-Allow-Headers字段,并且确保实际请求的方法和头信息在预检请求的响应中被允许。
  3. 请求中使用了非简单请求:非简单请求是指那些对服务器有特殊要求的请求,如使用了自定义的请求头字段、使用了非常见的请求方法(如PUT、DELETE等)、发送了包含文件上传的请求等。对于非简单请求,浏览器会先发送一个预检请求,以获取服务器对该请求的支持情况。在预检请求的响应中,除了设置Access-Control-Allow-Origin字段,还需要设置Access-Control-Allow-Methods和Access-Control-Allow-Headers字段,并且确保实际请求的方法和头信息在预检请求的响应中被允许。
  4. 服务端设置的Access-Control-Allow-Origin字段不正确:Access-Control-Allow-Origin字段用于指定允许跨域请求的源,可以设置为具体的域名或通配符""。如果设置为具体的域名,则只有该域名下的请求才被允许跨域访问;如果设置为"",则允许所有域名的请求跨域访问。需要确保设置的值与实际请求的源一致,否则会导致跨域错误。
  5. 服务端设置的Access-Control-Allow-Origin字段未包含请求的端口号:如果请求的源包含了端口号,那么在设置Access-Control-Allow-Origin字段时,需要将端口号一并设置。例如,如果请求的源为http://example.com:8080,那么Access-Control-Allow-Origin字段的值应为http://example.com:8080,而不仅仅是http://example.com。

综上所述,当在服务端设置Access-Control-Allow-Origin后仍然出现跨域错误时,需要检查以上几个方面的原因,并进行相应的调整和修正。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

Nginx 轻松搞定问题!

主要涉及4个响应头: Access-Control-Allow-Origin 用于设置允许请求源地址 (预检请求和正式请求时候都会验证) Access-Control-Allow-Headers...是否允许使用cookies,如果要使用cookies,可以添加上此请求响应头,值设为true(设置或者不设置,都不会影响请求发送,只会影响时候是否要携带cookies,但是如果设置,预检请求和正式请求都需要设置...通过错误信息可以很清晰的定位到错误(注意看标红部分)priflight说明是个预请求,CORS 机制会首先进行 preflight(一个 OPTIONS 请求), 该请求成功才会发送真正的请求。...情况4: 比较早期的API可能只用到了POST和GET请求,而Access-Control-Allow-Methods这个请求响应头默认只支持POST和GET,当出现其他请求类型时候,同样会出现异常...所以为什么说要不服务端代码层面解决,要不就Nginx代理解决,不要混着搞,不然不明白原理的人,网上找一段代码贴就很可能解决不了问题) ↓ ↓ ↓ ↓ ↓ 再贴一份完整配置(*号根据自己‘喜好’填写)

5.1K30

解决 用 Nginx 处理 问题

主要涉及4个响应头: Access-Control-Allow-Origin 用于设置允许请求源地址 (预检请求和正式请求时候都会验证) Access-Control-Allow-Headers...是否允许使用cookies,如果要使用cookies,可以添加上此请求响应头,值设为true(设置或者不设置,都不会影响请求发送,只会影响时候是否要携带cookies,但是如果设置,预检请求和正式请求都需要设置...通过错误信息可以很清晰的定位到错误(注意看标红部分)priflight说明是个预请求,CORS 机制会首先进行 preflight(一个 OPTIONS 请求), 该请求成功才会发送真正的请求。...POST和GET,当出现其他请求类型时候,同样会出现异常。...所以为什么说要不服务端代码层面解决,要不就Nginx代理解决,不要混着搞,不然不明白原理的人,网上找一段代码贴就很可能解决不了问题) 再贴一份完整配置(*号根据自己‘喜好’填写): server {

1.7K22
  • AJAX 三连问,你能顶住么?

    从入坑前端开始,一直到现在,AJAX请求都是以极高的频率重复出现,也解决过不少AJAX中遇到的问题,如调试,错误调试等等。...AJAX出现时,那时的服务端还是很古老的那一批,因此完全没有考虑到AJAX出现,前端请求方式会变得异常复杂,造成以前的安全策略已经无法满足要求了,导致大批的后台安全漏洞曝光。。。...很显然,都是因为AJAX出现曝光了更多的安全漏洞,导致它看起来很危险(因为AJAX出现,请求方式变多了,以前的架构新的请求中就可能出现更多漏洞) So,AJAX不安全的说法自然扩散到了各个角落。...,而且这时候不允许设置Allow-Origin: *),所以肯定认证失败 可以看到,就算Access-Control-Allow-Origin: *允许所有来源的AJAX请求,的cookie默认情况下仍然是无法携带的...报错误。 以上仅是简介,更多信息可以参考来源中的ajax,这应该是最全的解决方案了 为什么要配置CORS? 因为同源策略限制,AJAX无法请求资源,CORS可以解决AJAX请求问题。

    1.1K21

    如何配置ajax请求携带cookie,cors支持ajax请求携带cookie

    首先咱们来看一下前后端数据交互的一些规则: 1、同域名下发送ajax请求,请求中默认会携带cookie 2、ajax发送请求时,默认情况下是不会携带cookie的 3、ajax发送请求时如果想携带...此时cookie又回来了,到此为止前端人员的设置就算完成了,虽然现在ajax执行,最终调用的是错误回调,那是因为后端还不支持cors。...响应头中设置了Access—Control—Allow—Origin:*,说明已经支持了。 但是ajax调用后执行的还是错误回调,并且console面板打印了一个错误: ?...响应头中Access-Control-Allow-Origin的值设置成了白名单,但是等等,此时为什么ajax调用后,还是执行错误毁掉呢?...如果设置白名单的话,这个响应头浏览器中是不会出现的,想想也是,设置了白名单就是为了不让信息泄密啊。

    16.9K31

    ajax,这应该是最全的解决方案了

    方式 代理请求方式 如何分析ajax http抓包的分析 一些示例 什么是ajax ajax的原理 ajax出现请求错误问题,主要原因就是因为浏览器的“同源策略”,可以参考 CORS请求原理...:* 说实话,这种问题出现的主要原因就是进行配置的人不了解原理,导致了重复配置,如: 常见于.net后台(一般web.config中配置了一次origin,然后代码中又手动添加了一次origin(...比如代码手动设置了返回*)) 常见于.net后台(IIS和项目的webconfig中同时设置Origin:*) 解决方案(一一对应): 建议删除代码中手动添加的*,只用项目配置中的即可 建议删除IIS...示例二(错误的ajax请求) 为了方便,我们仍然拿上面的错误表现示例举例。...这个请求中,接口Allow里面没有包括OPTIONS,所以请求出现、 这个请求中,Access-Control-Allow-Origin: *出现了两次,导致了配置没有正确配置,出现错误

    1.7K70

    一次问题的分析

    事件起因 一个需求让我开放一个 HTTP 接口给前端,联调的过程中,前端请求时出现了一个 CORS 错误,也即问题,错误如下 一开始我的想法是,问题,这我熟啊,在学校写代码的时候就经常遇到,这解决起来不是分分钟的吗...使用 WebMvcConfigurer 配置的 addCorsMappings 方法配置接口 3 时失败,仍然出现问题。...因此才会出现这种情况,当你项目中使用了该方法配置问题,再使用自定义的拦截器时,问题的相关配置就会失效,请求依然会报问题的错。...配置好拦截器之后,仍然出现问题,此时的我心态崩了。...验证:修改 nginx 的 proxy_intercept_errors 配置选项,将拦截关闭 预期效果:不会重定向,且出现原生的 tomcat 错误页面 实验: 控制台 fetch 时也不会出现错误

    1.2K10

    CORS解决问题

    1.1 不同源则触发一个的HTTP请求: 浏览器中,当 “一个资源” 向 “与它所在的服务器不同的、协议或端口” 请求一个资源时,该资源会发起一个 HTTP 请求。...CORS请求失败会产生错误,但是为了安全,JavaScript代码层面是无法获知到底具体是哪里出了问题。你只能查看浏览器的控制台以得知具体是哪里出现错误。 3....示例: X-PINGOTHER: pingpong Origin: http://foo.example (4) 服务端服务端 根据实际情况处理请求,仍然要返回 Access-Control-Allow-Origin...如果在这个过程中发生了“拒绝”,那么,发送预检请求,就没后续了,浏览器会 “不再发送实际的请求”,或者 “丢失实际请求中的响应”。...3.3 附带携带身份凭据的请求 对于 请求,浏览器不会发送身份凭证信息。如果要发送凭证信息,需要设置 XMLHttpRequest 的某个特殊标志位。

    1.9K10

    ajax解决方案_java如何解决问题

    JSONP方式 CORS方式 代理请求方式 如何分析ajax http抓包的分析 一些示例 什么是ajax ajax的原理 ajax出现请求错误问题...:* 说实话,这种问题出现的主要原因就是进行配置的人不了解原理,导致了重复配置,如: 常见于.net后台(一般web.config中配置了一次origin,然后代码中又手动添加了一次origin...(比如代码手动设置了返回*)) 常见于.net后台(IIS和项目的webconfig中同时设置Origin:*) 解决方案(一一对应): 建议删除代码中手动添加的*,只用项目配置中的即可...示例二(错误的ajax请求) 为了方便,我们仍然拿上面的错误表现示例举例。...这个请求中,接口Allow里面没有包括 OPTIONS,所以请求出现、 这个请求中, Access-Control-Allow-Origin:*出现了两次,导致了配置没有正确配置,出现错误

    1.1K40

    了解前端知识

    这也就是为什么出现通过 API 请求工具调用接口的时候没有问题,但通过浏览起发起请求时就会出现警告。 4. 请求,浏览器会做什么?...响应返回浏览器接收到响应,会校验以下响应头中的字段,确认服务端是否允许本次请求: Access-Control-Allow-Origin服务端设置的允许共享资源的源): 是否包含该请求源或者设置为所有源...表现: 满足服务器设置时,简单请求返回响应数据,非简单请求发送后续的真实请求(后续响应的处理和上述相同)。 不满足服务器设置时,简单请求返回的响应数据会直接被浏览器拦截,抛出错误。...CORS(推荐)服务端设置 Access-Control-Allow-Origin,将需要发送请求的请求源设置到该字段中,便可支持请求。...C,就可以名正言顺的拿到刚才设置 window.name 里的资源了。

    49320

    ajax,这应该是最全的解决方案了

    :* 说实话,这种问题出现的主要原因就是进行配置的人不了解原理,导致了重复配置, 如: •常见于.net后台(一般web.config中配置了一次origin,然后代码中又手动添加了一次origin...(比如代码手动设置了返回*)) •常见于.net后台(IIS和项目的webconfig中同时设置Origin:*) 解决方案(一一对应): •建议删除代码中手动添加的*,只用项目配置中的即可 •建议删除...允许,比如: •第二步:其它更多配置,如果第一步进行了,仍然问题,可能是:  ∷接口中有限制死一些请求类型(比如写死了POST等),这时候请去除限制   ∷接口中,重复配置了Origin:*,...示例二(错误的ajax请求) 为了方便,我们仍然拿上面的错误表现示例举例。...这个请求中,接口Allow里面没有包括OPTIONS,所以请求出现、 这个请求中,Access-Control-Allow-Origin: *出现了两次,导致了配置没有正确配置,出现错误

    73720

    Web漏洞 | CORS资源共享漏洞

    简单请求就是使用设定的请求方式请求数据,而非简单请求则是使用设定的请求方式请求数据之前,先发送一个OPTIONS预检请求,验证请求源是否为服务端允许源。...如下,简单请求头: CORS服务端会将该字段作为源标志。CORS接收到此次请求, 首先会判断Origin是否允许源(由服务端决定)范围之内。...总结:简单请求只需要CORS服务端接受到携带Origin字段的请求response header中添加Access-Control-Allow-Origin等字段给浏览器做同源判断。...通过上面叙述,我们得知借助CORS我们不必关心发出的请求是否,浏览器会帮我们处理这些事情,但是服务端需要支持CORS,服务端实现CORS的原理也很简单,服务端完全可以对请求做上下文处理,已达到接口允许访问的目的...1:CORS服务端Access-Control-Allow-Origin 设置为了 *,并且 Access-Control-Allow-Credentials 设置为false,这样任何网站都可以获取该服务端的任何数据了

    1.3K10

    Web漏洞 | CORS资源共享漏洞

    简单请求就是使用设定的请求方式请求数据,而非简单请求则是使用设定的请求方式请求数据之前,先发送一个OPTIONS预检请求,验证请求源是否为服务端允许源。...CORS服务端会将该字段作为源标志。CORS接收到此次请求, 首先会判断Origin是否允许源(由服务端决定)范围之内。...总结:简单请求只需要CORS服务端接受到携带Origin字段的请求response header中添加Access-Control-Allow-Origin等字段给浏览器做同源判断。...通过上面叙述,我们得知借助CORS我们不必关心发出的请求是否,浏览器会帮我们处理这些事情,但是服务端需要支持CORS,服务端实现CORS的原理也很简单,服务端完全可以对请求做上下文处理,已达到接口允许访问的目的...1:CORS服务端Access-Control-Allow-Origin 设置为了 *,并且 Access-Control-Allow-Credentials 设置为false,这样任何网站都可以获取该服务端的任何数据了

    6.8K20

    问题详解

    3.1 打破浏览器的限制 由上面分析结论可知,之所以出现错误,实际上是客户端浏览器所做的限制,服务器并未进行限制,因此我们可以通过设置浏览器,使其不进行检查。...[错误] 回到文章开始的这个错误信息,可以看到错误的具体信息是:服务端没有设置Access-Control-Allow-Origin 这个响应头从而导致报错,通过设置 Access-Control-Allow-Origin...但是,这种设置能满足所有情况吗? 更进一步,使用 CORS 时浏览器如何检查错误? 前面我们有讲到,虽然浏览器报错,但是在这之前服务端已经接受了请求,那么,浏览器总是先发出请求再进行判断吗?...3.3.1 浏览器如何检查错误 浏览器检查错误的基本原理是: 浏览器检测到 ajax 请求的与当前不一致,会在请求头中增加 Origin 字段,然后检查服务端响应头 Access-Control-Allow-Origin...,缓存有效期内,非简单请求可以不发送预检请求,另外,实际开发中,可以服务端设置接收到的请求方法是 OPTIONS 时,直接返回 200,这样也能加快响应。

    2.7K30

    Cors(三):Access-Control-Allow-Origin多域名?

    本文将实战Cors解决问题中最为重要的响应头:Access-Control-Allow-Origin。它用于服务端告诉浏览器允许共享本资源的Origin,那么如何允许多个域名呢?...版本约定 JDK:8 Servlet:4.x tomcat:9.x 正文 正如前文所述,响应头Access-Control-Allow-Origin 用于请求中告诉浏览器服务端允许的Origin,...多说一句:实际开发中这种出现两个Access-Control-Allow-Origin响应头的case还是比较常见的。...别问我为什么会知道,因为我就曾被安全部门同事招呼过? 最佳实践 来了,期待的最佳实践它来了。允许多域名是如此常见的场景,本文当然要给出最佳实践(供以参考)。...既然浏览器是精确的完整匹配这个规则我们无法修改,那只有唯一的一个办法:服务端Access-Control-Allow-Origin赋值之前做逻辑: 若允许,将请求的Origin赋值给它 若不允许

    6.2K32

    Web Security 之 CORS

    由于应用程序 Access-Control-Allow-Origin 头中直接返回了请求,这意味着任何都可以访问资源。...内网的安全标准通常低于外网,这使得攻击者发现漏洞可以获得进一步的访问权限。例如,某个私有网络中的请求: GET /reader?...因此,除了正确配置的 CORS 之外,web 服务端仍然需要使用诸如身份验证和会话管理等措施对敏感数据进行保护。...下表显示了如果上述 URL 中的内容尝试访问其它源将会是什么情况: 是,同源 *IE 浏览器将会允许访问,因为 IE 浏览器应用同源策略时不考虑端口号。 为什么同源策略是必要的?...某些情况下,当请求包括非标准的 HTTP method 或 header 时,进行请求之前,浏览器会先发起一次 method 为 OPTIONS 的请求,并且对服务端响应的 Access-Control

    1.3K10

    nginx配置访问,无法生效_页面访问

    即会出现请求禁止。...通俗一点说就是如果存在协议、域名、端口或者子域名不同服务端,或一者为IP地址,一者为域名地址(问题上,仅仅是通过”url的首部”来识别而不会去尝试判断相同的IP地址对应着两个或者两个是否同属同一个...IP),之中任意服务端旗下的客户端发起请求其它服务端资源的访问行动都是的,而浏览器为了安全问题一般都限制了访问,也就是不允许请求资源。...需要服务器设置header:Access-Control-Allow-Origin 4.Nginx反向代理 可以不需要目标服务器配合,不过需要Nginx中转服务器,用于转发请求(服务端之间的资源请求不会有限制...) Nginx访问解决方案 使用Ajax请求资源,Nginx作为代理,出现以下错误: The 'Access-Control-Allow-Origin' header contains multiple

    7.3K20

    问题及解决方案

    问题及解决方案 一、介绍 在前后端分离项目中,问题是一定会遇到的。问题的出现,会导致css、js或者ajax对后端请求等资源无法访问的情况。...后端设置Access-Control-Allow-Origin(* 或者 传入的Origin)响应头,表示同意本次请求 浏览器识别是否有Access-Control-Allow-Origin...允许,发送真正的请求,携带真实的数据进行传输请求 如果不允许,则控制台打印报错,不会发送真正的请求 注意: CORS默认不发送Cookie,想要发送cookie必须如下设置...options请求 浏览器地址栏输入chrome://flags/#out-of-blink-cors 将其设置为disabled,然后重启浏览器 三、CORS服务端设置响应 1、SpringBoot...也就是说,add_header可以最上层统一设置,然后个性化独立设置 Nginx 1. 7. 5增加了always语法,即便后端接口发生500错误设置的响应头也能生效 简单使用 server {

    1.1K50

    后端工程师需要了解的知识

    1 遇见 产品有多端:机构端,局方端 ,家长端等 。每端都有独立的域名,有的是PC上访问,有的是通过微信公众号来访问,有的是扫码H5展现。...服务器端接到请求,会根据自己的规则,通过Access-Control-Allow-Origin和Access-Control-Allow-Methods响应头,来返回验证结果。...得到服务器的授权才能发送真正的HTTP请求。 OPTIONS请求头部中会包含以下头部: 服务器收到OPTIONS请求设置头部与浏览器沟通来判断是否允许这个请求。...可是公司内网访问演示环境,有一个页面一直报CORS报错,报错内容类似下图: 错误类型是:InsecurePrivateNetwork。 这和原来遇到的错误完全不一样,我心里一慌。...内部服务端不用特别关注这个问题。 同时,解决的问题过程中,我的心态也发生了变化。

    89910

    vue配置

    域名不同,前者是test,后者是test2 http://www.test.com:8080/ http://www.test.com:8002/ 是 端口不同,前者是8080,后者是8002 2、为什么出现...因为端口不同,所以会触发同源策略,报错误,浏览器不显示数据。...5、附-服务端配置 当然,我们也可以直接在后端服务器做相应配置,这里就以express为例: // 配置关键代码Access-Control-Allow-Origin与Access-Control-Allow-Methods...如上配置,由于服务端设置了res.header('Access-Control-Allow-Origin', 'http://localhost:8080'),如果请求数据的源是 http://localhost...4、总结 以上就是关于及Vue配置的基本内容。首先介绍了什么是为什么出现?接着重点介绍了Vue中如何配置。最后还提供了服务端(express)的配置。

    7710

    AJAX 与通信(二):解决方案

    JSONP 获取 CSS, 获取 JS, 获取图片,这些明明也是获取资源,为什么不会被禁止呢?...然后是服务端的角度,服务端收到请求,首先检测请求报头的 Origin 是否自己的许可范围内, 如果确实是许可的,那么待会响应的时候,响应头会额外增加如下字段: Access-Control-Allow-Origin...如果不是许可的,那么这时候其实压根不会返回 Access-Control-Allow-Origin 这个响应头,而浏览器会捕获这次错误,如下图所示: image.png PS:虽然禁止 AJAX...,但是呢,我们注意到这两个的主是相同的,只是子不同而已,所以我们可以用 document.domain 的方法实现,具体来说,就是重新设置两个页面的 document.domain 为一个相同的值...= 'test.com'; // 虽然本来就是 test.com,但还是要显式设置一次 之后,我们就可以 A 域中拿到 B 的东西了。

    1.3K10
    领券