Nginx系列教程(10)基于Nginx解决前端访问后端服务跨域问题(Session和cookie无效)

admin • 2020年4月29日 am9:45 • Nginx实战教程 • 阅读 1006

文章目录

问题背景
解决方法
总结
备注
往期文章

问题背景

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

有两个项目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<sl_domain>-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: