基于Nginx解决前端访问服务器跨域问题(Session和cookie无效)

简介:

问题背景

这两天遇到一个这样的需求:

有两个项目a和b,在a项目中有页面需要调用b中的接口,两项目的域名不同,分别为a.com, b.com。这时候如果直接调用,显然跨域了。一番折腾之后,问题解决了,这里记录一下解决方法。

解决方法

第一步,解决跨域

这个使用Nginx的代理功能即可,在a服务器的Nginx添加如下示例配置:

location ~ /xxx/ {
proxy_pass http://b.com;
}

这样就把路径中带有/xxx/的请求都转到了b.com。如果不需要保存cookie,保持session这样的功能,这样就可以了。

然而,本项目就是要用到cookie,所以就有了下边的内容。

第二步,设置domain

因为cookie当中是有domain的,两个服务器的一般不同,比如a服务器返回的Response Headers中是

Set-Cookie:JSESSIONID=_3y4u02v4cbpBw10DoCrMSnjg7m34xuum1XRWBF1Uno; path=/; domain=a.com

而b服务器返回的是

Set-Cookie:JSESSIONID=_3y4u02v4cbpBw10DoCrMSnjg7m34xuum1XRWBF1Uno; path=/; domain=b.com

这时候如果a项目的页面调用了b的接口,浏览器发现接口返回的domain不是a.com,就不会把cookie保存起来,session也就失效了。Nginx 引入了proxy_cookie_domain来解决这个问题。示例:

location ~ /xxx/ {
proxy_cookie_domain b.com a.com;
proxy_pass http://b.com;
}

这样就可以在Nginx转接请求的时候自动把domain中的b.com 转换成 a.com,这样cookie就可以设置成功了。

但是,对于有些情况这样转换不灵光。比如,b项目的domain是.b.com,前边多了一个小点,那对应的改为 proxy_cookie_domain .b.com a.com; 可以不?通过实践,不行!!!

通过查看Nginx文档,找到了解决办法。其实,除了上边那种配置方式外,Nginx还支持正则配置:

location ~ /xxx/ {
proxy_cookie_domain ~\.?b.com a.com;
proxy_pass http://b.com;
}

这样就可以把domain中的.b.com 转换成 a.com啦。

第三步,设置path

正常情况下完成以上两步就可以了,因为cookie中的path一般默认的是path=/,也就是所有请求都可以访问本cookie。但有些服务器会指定,只允许某个层级下的请求可以访问cookie,比如:

Set-Cookie:JSESSIONID=_3y4u02v4cbpBw10DoCrMSnjg7m34xuum1XRWBF1Uno; path=/sub/; domain=b.com

这样就只允许相对根路径,以/sub/开头的请求路径才能访问cookie。这时候就又可能出现cookie无效的问题了,为了解决这个问题,可以使用proxy_cookie_path。示例:

location ~ /xxx/ {
proxy_cookie_domain ~\.?b.com a.com;
proxy_cookie_path /sub/ /;
proxy_pass http://b.com;
}

这样就把只允许/sub/层级下的请求访问cookie,改为允许所有请求访问cookie了。

总结

折腾了几个小时,还是在Nginx官方文档找到了解决方案。说了这么多,其实只要这样简单的几行配置就可以搞定跨域cookie了。希望本文能够对你有所帮助。

备注

Nginx文档节选内容:

Syntax: proxy_cookie_domain off;
proxy_cookie_domain domain replacement;
Default:
proxy_cookie_domain off;
Context: http, server, location

This directive appeared in version 1.1.15.

Sets a text that should be changed in the domain attribute of the “Set-Cookie” header fields of a proxied server response. Suppose a proxied server returned the “Set-Cookie” header field with the attribute “domain=localhost”. The directive

proxy_cookie_domain localhost example.org;

will rewrite this attribute to domain=example.org.

A dot at the beginning of the domain and replacement strings and the domain attribute is ignored. Matching is case-insensitive.

The domain and replacement strings can contain variables:

proxy_cookie_domain www.$host $host;

The directive can also be specified using regular expressions. In this case, domain should start from the “~” symbol. A regular expression can contain named and positional captures, and replacement can reference them:

proxy_cookie_domain ~.(?P-0-9a-z+.a-z+)$ $sl_domain;

There could be several proxy_cookie_domain directives:

proxy_cookie_domain localhost example.org;
proxy_cookie_domain ~.(a-z+.a-z+)$ $1;

The off parameter cancels the effect of all proxy_cookie_domain directives on the current level:

proxy_cookie_domain off;
proxy_cookie_domain localhost example.org;
proxy_cookie_domain www.example.org example.org;
proxy_cookie_path off;
proxy_cookie_path path replacement;

Default:

proxy_cookie_path off;
Context: http, server, location

This directive appeared in version 1.1.15.

Sets a text that should be changed in the path attribute of the “Set-Cookie” header fields of a proxied server response. Suppose a proxied server returned the “Set-Cookie” header field with the attribute “path=/two/some/uri/”. The directive

proxy_cookie_path /two/ /;

will rewrite this attribute to “path=/some/uri/”.

The path and replacement strings can contain variables:

proxy_cookie_path $uri /some$uri;

The directive can also be specified using regular expressions. In this case, path should either start from the “~” symbol for a case-sensitive matching, or from the “~*” symbols for case-insensitive matching. The regular expression can contain named and positional captures, and replacement can reference them:

proxy_cookie_path ~*^/user/(^/+) /u/$1;

There could be several proxy_cookie_path directives:

proxy_cookie_path /one/ /;
proxy_cookie_path / /two/;

The off parameter cancels the effect of all proxy_cookie_path directives on the current level:

proxy_cookie_path off;
proxy_cookie_path /two/ /;
proxy_cookie_path ~*^/user/(^/+) /u/$1;

参考文档:https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cookie_domain

1,Nginx英文帮助文档

2,Nginx中文帮助文档

往期文章

Nginx系列教程(1)nginx基本介绍和安装入门

Nginx系列教程(2)nginx搭建静态资源web服务器

Nginx系列教程(3)nginx缓存服务器上的静态文件

Nginx系列教程(4)nginx处理web应用负载均衡问题以保证高并发

Nginx系列教程(5)如何保障nginx的高可用性(keepalived)

Nginx系列教程(6)nginx location 匹配规则详细解说

Nginx系列教程(7)nginx rewrite配置规则详细说明

Nginx系列教程(8)nginx配置安全证书SSL

Nginx系列教程(9)nginx 解决session一致性

相关文章
|
存储 前端开发 安全
前端如何存储数据:Cookie、LocalStorage 与 SessionStorage 全面解析
本文全面解析前端三种数据存储方式:Cookie、LocalStorage与SessionStorage。涵盖其定义、使用方法、生命周期、优缺点及典型应用场景,帮助开发者根据登录状态、用户偏好、会话控制等需求,选择合适的存储方案,提升Web应用的性能与安全性。(238字)
696 0
|
10月前
|
前端开发 Cloud Native Java
Java||Springboot读取本地目录的文件和文件结构,读取服务器文档目录数据供前端渲染的API实现
博客不应该只有代码和解决方案,重点应该在于给出解决方案的同时分享思维模式,只有思维才能可持续地解决问题,只有思维才是真正值得学习和分享的核心要素。如果这篇博客能给您带来一点帮助,麻烦您点个赞支持一下,还可以收藏起来以备不时之需,有疑问和错误欢迎在评论区指出~
Java||Springboot读取本地目录的文件和文件结构,读取服务器文档目录数据供前端渲染的API实现
|
存储 弹性计算 算法
前端大模型应用笔记(四):如何在资源受限例如1核和1G内存的端侧或ECS上运行一个合适的向量存储库及如何优化
本文探讨了在资源受限的嵌入式设备(如1核处理器和1GB内存)上实现高效向量存储和检索的方法,旨在支持端侧大模型应用。文章分析了Annoy、HNSWLib、NMSLib、FLANN、VP-Trees和Lshbox等向量存储库的特点与适用场景,推荐Annoy作为多数情况下的首选方案,并提出了数据预处理、索引优化、查询优化等策略以提升性能。通过这些方法,即使在资源受限的环境中也能实现高效的向量检索。
759 1
|
前端开发 开发工具 git
如何清理 docker 磁盘空间+修改 Gitea 服务器的 Webhook 设置+前端一些好学好用的代码规范-git hook+husky + commitlint
如何清理 docker 磁盘空间+修改 Gitea 服务器的 Webhook 设置+前端一些好学好用的代码规范-git hook+husky + commitlint
253 5
axios允许跨域cookie
axios允许跨域cookie
138 4
|
JavaScript 前端开发 应用服务中间件
vue前端开发中,通过vue.config.js配置和nginx配置,实现多个入口文件的实现方法
vue前端开发中,通过vue.config.js配置和nginx配置,实现多个入口文件的实现方法
791 0
|
前端开发 应用服务中间件 nginx
前端服务器部署方式
【8月更文挑战第25天】前端服务器部署方式
735 1
|
前端开发 大数据 数据库
🔥大数据洪流下的决战:JSF 表格组件如何做到毫秒级响应?揭秘背后的性能魔法!💪
【8月更文挑战第31天】在 Web 应用中,表格组件常用于展示和操作数据,但在大数据量下性能会成瓶颈。本文介绍在 JavaServer Faces(JSF)中优化表格组件的方法,包括数据处理、分页及懒加载等技术。通过后端分页或懒加载按需加载数据,减少不必要的数据加载和优化数据库查询,并利用缓存机制减少数据库访问次数,从而提高表格组件的响应速度和整体性能。掌握这些最佳实践对开发高性能 JSF 应用至关重要。
278 0
|
存储 设计模式 运维
Angular遇上Azure Functions:探索无服务器架构下的开发实践——从在线投票系统案例深入分析前端与后端的协同工作
【8月更文挑战第31天】在现代软件开发中,无服务器架构因可扩展性和成本效益而备受青睐。本文通过构建一个在线投票应用,介绍如何结合Angular前端框架与Azure Functions后端服务,快速搭建高效、可扩展的应用系统。Angular提供响应式编程和组件化能力,适合构建动态用户界面;Azure Functions则简化了后端逻辑处理与数据存储。通过具体示例代码,详细展示了从设置Azure Functions到整合Angular前端的全过程,帮助开发者轻松上手无服务器应用开发。
159 0
|
前端开发 JavaScript API
Web服务器与前端技术的集成
【8月更文第28天】随着Web开发技术的发展,现代前端框架如React、Vue.js等已经成为构建复杂Web应用的标准工具。为了提供更好的用户体验,这些前端应用通常需要与后端Web服务器进行紧密集成。本文将详细介绍如何将React和Vue.js与后端Web服务器无缝集成,以创建高性能且用户友好的Web应用。
250 0