北京网页制作方案seo网站做推广

北京网页制作方案,seo网站做推广,湛江专业做网站,无锡网络公司文章目录引言同源策略跨域问题如何产生#xff1f;解决方案一#xff1a;CORS#xff08;跨源资源共享#xff09;1. 简单请求#xff08;Simple Requests#xff09;2. 预检请求#xff08;Preflighted Requests#xff09;代码示例Java (Spring Boot 示例)Go (Gin 框…文章目录引言同源策略跨域问题如何产生解决方案一CORS跨源资源共享1. 简单请求Simple Requests2. 预检请求Preflighted Requests代码示例Java (Spring Boot 示例)Go (Gin 框架示例)解决方案二反向代理集中管理与解耦安全性与架构优势架构示意图总结引言在平时的后台开发中我们会经常遇到跨域问题那么跨域问题到底是什么怎么去解决跨域问题呢今天我们就一起探讨一下。同源策略跨域问题本质上是由于浏览器的同源策略Same-Origin Policy引起的。同源策略是浏览器的一个安全限制。它规定一个源Origin的文档或脚本只能与同源的资源进行交互。“源”由三个部分组成协议Protocol、主机Host/Domain和端口号Port。如果请求的 URL 与当前页面的 URL 相比任一部分不同就被认为是跨源。当前页面 URL目标 URL是否同源跨源原因http://a.com:8080/index.htmlhttp://a.com:8080/data.json是(全部相同)http://a.com:8080/**https**://a.com:8080/否协议不同 (httpvshttps)http://a.com:8080/http://**b.com**:8080/否主机不同 (a.comvsb.com)http://a.com:8080/http://a.com:**9090**/**否端口不同 (8080vs9090)同源策略的目的是保护用户安全和隐私防止恶意网站通过浏览器脚本访问其他网站的敏感数据。跨域问题如何产生当浏览器中的前端代码如使用XMLHttpRequest或FetchAPI尝试向一个不同源的服务器发起 HTTP 请求时浏览器会拦截服务器返回的数据导致请求失败但在网络层面上请求实际上已经发送到服务器并收到了响应。这就是我们在开发中常说的跨域报错通常你会看到类似No Access-Control-Allow-Origin header is present on the requested resource的错误信息。解决方案一CORS跨源资源共享在本地开发测试阶段可以通过配置cors来解决跨域问题。跨源资源共享Cross-Origin Resource Sharing,CORS是一种允许浏览器放宽同源策略限制的机制。它通过在服务器端设置特定的HTTP 响应头来告知浏览器该服务器允许哪些源访问其资源。CORS 主要分为两种请求模式1. 简单请求Simple Requests如果请求同时满足以下所有条件则被认为是简单请求方法只能是GET、POST、HEAD之一。请求头只能包含少数几个安全的请求头如Accept、Accept-Language、Content-Language、Content-Type等且Content-Type只能是以下三种之一application/x-www-form-urlencodedmultipart/form-datatext/plain工作流程浏览器直接发送请求并在请求头中带上Origin字段表明自己的源。服务器收到请求后如果允许跨源访问则在响应头中加入Access-Control-Allow-Origin字段指定允许的源例如Access-Control-Allow-Origin: http://client.com或Access-Control-Allow-Origin: *。浏览器检查响应头如果发现Access-Control-Allow-Origin允许当前源则将数据交给前端代码否则抛出跨域错误。2. 预检请求Preflighted Requests对于非简单请求例如使用了PUT、DELETE方法或者设置了自定义请求头浏览器会先发送一个使用OPTIONS方法的预检请求以确定服务器是否安全。工作流程浏览器发送OPTIONS预检请求请求头包含Origin当前源。Access-Control-Request-Method实际请求将使用的方法如POST。Access-Control-Request-Headers实际请求将携带的自定义请求头如X-Custom-Header。服务器处理预检请求服务器检查这些请求头如果允许则在预检请求的响应头中返回Access-Control-Allow-Origin允许的源。Access-Control-Allow-Methods允许的方法。Access-Control-Allow-Headers允许的自定义请求头。Access-Control-Max-Age预检结果的缓存时间秒。浏览器检查预检结果如果预检通过浏览器才会发送实际的 HTTP 请求GET/POST/PUT/DELETE 等。服务器处理实际请求并返回数据响应头中通常仍会包含Access-Control-Allow-Origin。代码示例Java (Spring Boot 示例)在 Spring Boot 中你可以通过配置WebMvcConfigurer或在 Controller 上使用CrossOrigin注解来解决// 方法一全局配置 (推荐)ConfigurationpublicclassCorsConfigimplementsWebMvcConfigurer{OverridepublicvoidaddCorsMappings(CorsRegistryregistry){registry.addMapping(/**)// 匹配所有路径.allowedOrigins(http://your-frontend-domain.com)// 允许的源可以设为 * 允许所有不推荐用于生产.allowedMethods(GET,POST,PUT,DELETE,OPTIONS)// 允许的方法.allowedHeaders(*)// 允许所有请求头.allowCredentials(true)// 是否允许携带 Cookie.maxAge(3600);// 预检请求的缓存时间}}Go (Gin 框架示例)如果你使用 Gin 框架可以借助第三方 CORS 中间件例如github.com/gin-contrib/cors// Go 示例 (使用 Gin 框架和 gin-contrib/cors 中间件)packagemainimport(timegithub.com/gin-contrib/corsgithub.com/gin-gonic/gin)funcmain(){r:gin.Default()// 配置 CORS 中间件r.Use(cors.New(cors.Config{AllowOrigins:[]string{http://your-frontend-domain.com},// 允许的源AllowMethods:[]string{GET,POST,PUT,DELETE,OPTIONS},AllowHeaders:[]string{Origin,Content-Type,Authorization},// 允许的请求头ExposeHeaders:[]string{Content-Length},// 允许前端访问的响应头AllowCredentials:true,// 允许携带 CookieMaxAge:12*time.Hour,}))r.GET(/ping,func(c*gin.Context){c.JSON(200,gin.H{message:pong,})})r.Run()}解决方案二反向代理这是生产环境中最常用且推荐的方案。前端请求同源的代理服务器由代理服务器转发请求给目标服务器。因为请求发生在服务器之间不受浏览器同源策略限制。当浏览器向代理服务器例如http://api.frontend.com发送请求时由于前端页面和代理服务器是同源的浏览器不会触发同源策略限制。代理服务器在收到请求后再将其转发到后端服务例如http://backend-service:8080。服务器之间的通信不存在跨域限制集中管理与解耦将跨域配置、SSL/TLS 证书、负载均衡、限流、缓存等所有非业务性的公共配置全部集中在反向代理层处理。后端服务解耦后端服务Java/Go可以专注于业务逻辑无需关心这些基础设施配置。配置统一只需要在 Nginx 或 Gateway 上配置一次适用于所有后端服务安全性与架构优势隐藏真实服务地址客户端只能看到代理服务器的地址后端服务的真实 IP 和端口被隐藏提高了安全性。更细致的访问控制代理层可以更容易地实现基于路径的访问控制和限流架构示意图总结解决跨域问题在开发测试环境中为了简单快捷我们可以使用cors。在生产部署环境中强烈建议使用反向代理。