新版chrome浏览器重复跳转登陆问题分析

1.问题现象

最近我们系统的部分用户,使用chorme用户登陆系统后,仍然不断提示用户未登录并重复跳转登陆页面。

大家都知道开发中有测试环境、预发环境和线上环境,而上述问题仅出现在我们的预发环境和线上环境,测试环境确并没有该问题出现。是不是非常的奇怪~~~

很明显,该问题是由于服务端检测到用户未登录导致的,即使用户已进行过登陆操作,但服务端仍然认为用户登陆。那么,造成这种现象的原因是什么呢?

2.原因分析

2.1 服务登陆与鉴权

用户登陆与鉴权

2.2 原因分析

经观察发现,用于校验用户是否登陆的login接口在发送请求的时候,请求头中未携带用于后端用来鉴权的cookie。如图所示:

请求头无cookie信息


且提示:This Set-Cookie didn't specify a "SameSite" attribute and was defaulted to "SameSite=Lax" and was blocked because it came from a cross-site response which not the response to a top-level navigation. The Set-Cookie had to have been set with "SameSite=None" to enable cross-site usage

即:当Set-Cookie中的”SameSite“没有设置值时,默认为”SameSite=Lax“,并且因为Set-Cookie来自于一个跨站点的响应,导致Set-Cookie被阻拦。如果需要跨站点设置cookie,Set-Cookie必须设置为”SameSite=None“。

并且请求头中提示跨站:

跨站提示

题外话:76+版本以上的chrome浏览器,开发者面板中会提示几个Sec-Fetch开头的请求头:

Sec-Fetch-Dest:请求的目的地,即如何获取的数据

Sec-Fetch-Mode:请求模式

Sec-Fetch-Site:表示请求者来源与目标来源的关系

此部分内容请参考:https://www.cnblogs.com/fulu/p/13879080.html

好!题外话结束,回归正文。

通过以上现象,我们可以得出这样的结论:由于cookie跨站导致请求发送时,请求头中无法携带cookie,服务端判定用户未登陆导致的页面不断跳转到登陆页面。

那么是什么导致了cookie无法发送呢?

3.SameSite

SameSite详解:http://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html

原来,chrome浏览器为了防止CSRF攻击,为cookie增加了一个SameSite属性,在旧版本的浏览器中,该属性值默认为None,允许请求发送第三方cookie。但从2020年7月14日发布的chrome84稳定版开始,开始灰度SameSite灰度策略,设置默认属性值为SameSite=Lax。

这样我们就知道是由于谷歌浏览器的samesite灰度策略导致的请求无法发送cookie。

那么,我们如何解决该问题呢?

4.解决方案

4.1 关闭浏览器的samesite属性,操作步骤:地址栏输入 chrome://flags,把 SameSite by default cookies 改成 disabled 

4.2 保证前后端域名同站

此处需要解释一下跨站与跨域的区别。跨域要求非常严格,只要协议、域名或端口号不一致,就认为跨域。但cookie的跨站要求相对宽松,即eTLD+1(有效顶级域名左边加一个子域名)原则,只要eTLD+1相同,就认为是同站。如有效顶级域名为test.cn,那么a.test.cn 和 b.test.cn就是同站的,可以信任彼此的cookie。

这也就是解释了为什么我们的测试环境没有重复登陆的问题,就是因为测试环境eTLD+1是相同的,但线上和预发环境却不同。

4.3 调整登陆校验方式,不使用cookie校验

4.4 服务端将SameSite属性设置为None,但此时必须同时设置Secure属性(仅允许https协议发送cookie)。同时必须进行UA检测,因为IOS 12 的 Safari 以及老版本的一些 Chrome 会把 SameSite=none 识别成 SameSite=Strict,所以服务端必须在下发 Set-Cookie 响应头时进行 User-Agent 检测,对这些浏览器不下发 SameSite=none 属性。不兼容的客户端详见:https://www.chromium.org/updates/same-site/incompatible-clients

Java实战:

我尝试了使用以下几种方法来设置Cookie的SameSite属性

1.java sevlet的原生cookie尚未实现该属性,只能曲线救国了

2.通过HttpServletResponse 的setHeader方法,写一个filter来设置该属性,但是失败了。可能是因为Java本身未实现无法识别该属性。代码如下:



@Slf4j

@Configuration

@WebFilter(urlPatterns ="/*", filterName ="sameSiteFilter")

public class SameSiteFilterimplements javax.servlet.Filter {

@Override

    public void init(FilterConfig filterConfig)throws ServletException {

}

@Override

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)throws IOException, ServletException {

chain.doFilter(request, response);

        addSameSiteAttribute((HttpServletResponse) response); // add SameSite=strict cookie attribute

    }

private void addSameSiteAttribute(HttpServletResponse response) {

Collection headers = response.getHeaders("Set-Cookie");

        log.info("获取到的header信息:{}", JsonUtils.stringify(headers));

        boolean firstHeader =true;

        for (String header : headers) {

if (firstHeader) {

log.info("1cookie信息:{}",String.format("%s; %s", header, "SameSite=None;Secure"));

                response.setHeader("Set-Cookie", String.format("%s; %s", header, "SameSite=None;Secure"));

                firstHeader =false;

continue;

            }

log.info("2cookie信息:{}",String.format("%s; %s", header, "SameSite=None;Secure"));

            response.addHeader("Set-Cookie", String.format("%s; %s", header, "SameSite=None;Secure"));

        }

//重新获取cookie信息

        Collection headers1 = response.getHeaders("Set-Cookie");

        log.info("新获取到的header信息:{}",JsonUtils.stringify(headers1));

    }

@Override

    public void destroy() {

}

}


3.通过继承一个心的Cookie添加该属性,同样无法设置成功。代码如下:



class NewCookieextends Cookie {

private StringsameSite;

    public final static StringLAX ="Lax";

    public final static StringNONE ="None";

    public final static StringSTRICT ="Strict";

    public final static StringSET_COOKIE ="Set-Cookie";

    public NewCookie(String name, String value) {

super(name, value);

    }

public StringgetSameSite() {

return sameSite;

    }

public NewCookiesetSameSite(String sameSite) {

this.sameSite = sameSite;

        if (NONE.equals(sameSite)) {

setSecure(true);

        }

return this;

    }

@Override

    public StringtoString() {

// 参照Controller中的doSetCookie代码

        StringBuilder sb =new StringBuilder(getName()).append("=").append(getValue());

        sb.append(";Path=").append(getPath()==null?"/":getPath());

        if (getDomain() !=null) {

sb.append(";Domain=").append(getDomain());

        }

if (isHttpOnly()) {

sb.append(";HttpOnly");

        }

sb.append(";Max-Age=").append(getMaxAge());

        // 默认Lax

        sb.append(";SameSite=").append(getSameSite()==null?"Lax":getSameSite());

        if (getSecure()) {

sb.append(";Secure");

        }

if (getComment() !=null) {

sb.append(";Comment=").append(getComment());

        }

return sb.toString();

    }

}


4.新版本的spring-web包中的ResponseCookie虽然实现了SameSite,但我们项目Spring还是用的1.x的版本(接手的项目),不兼容!!!改造的成本比较高。

最后,我们决定先采用方案1,用户手动修改chrome浏览器,关闭samesite属性。

你可能感兴趣的:(新版chrome浏览器重复跳转登陆问题分析)