![cc11959d5490cb586deeddec2e35703f.png](https://i-blog.csdnimg.cn/blog_migrate/e4102b9dfc29574146bd43f46943fdce.png)
“ 临近年关,咨询师提出360,搜狗急速浏览器无法单点登陆到公司核心产品WD, 报重定向过多。
现象
经过测试, 出现单点登陆故障的是搜狗,360等主打双核(默认Chrome内核)的浏览器, 较新式的Edge、Chrome、Firefox均未出现此障碍。
![6d4433569ff9a9b4eb7ce205330326b5.png](https://i-blog.csdnimg.cn/blog_migrate/a1751c2cb5830f8673402e64f1f83bc6.jpeg)
“ Developer tool监测不到原始的SSO请求,互联网上同类型问题不少,答案却惨不忍睹,味同嚼蜡,人云亦云。 年末不能晚节不保,决心啃下硬骨头。
拿出网络分析利器Fiddler
![366e6cce5bb262be3402e89bd89713b4.png](https://i-blog.csdnimg.cn/blog_migrate/fe86f412be915cbc5dbef7ceb02c91fc.jpeg)
循环重定向?
显示单点登陆从业务站点重定向回首页,确实发生了循环重定向,搜狗浏览器做了重定向次数限制,最终返回浏览器定制的404 页面。 结合之前写的SSO 单点登陆原理,仔细分析站点发生循环重定向的原因:
![41d90f4b70ce498b6e3a48213b682e9b.png](https://i-blog.csdnimg.cn/blog_migrate/3cb18ac054e894f4dbe87208752e13eb.jpeg)
以上第⑥步,website1向浏览器写入Cookie for website1
之后,重定向回业务主页www.website1.com
⑦的时候,丢失了Cookie forwebsite1
,导致website1
认为用户未登陆,被迫重定向回sso-website.com?service=http://www.website1.com
②重新认证;
而sso-website.com
站点检测到Cookie for sso
(该用户已经认证),又开始走④⑤⑥⑦步骤,在第⑦步依旧没找到Cookie for website1
,又再次重定向回sso-website.com?service=http:///www.website1.com
,循环往复。
定位问题
熟稔web开发的都知道 Cookie for website1 会在请求http://website1.com时自然带上
Set-Cookie: X-Gridsum-FullTicketId=TGT-178876-em4uf0faD1c4pbt*********k5Z0vN4uPOoEBWfGIP6l-x-gridsumdissector; path=/; samesite=none; httponly
本处的问题在于最后一步重定向回首页的时候,没有带上该Cookie for website1
,下面是⑥----> ⑦步骤中,丢失Cookie for website1
的截图:
![70c71ba1b4f978745069d9edbcf86164.png](https://i-blog.csdnimg.cn/blog_migrate/7b34c7092e794f68e5365ad0c79e1f31.jpeg)
![ad1f8c4017a64fc002eda4c3677ce983.png](https://i-blog.csdnimg.cn/blog_migrate/1afecb5bbaf749c61b1e8620d8b96bc9.jpeg)
着重分析 Cookie for website1的附加属性:
Path 指示需要发送该cookie头的根url, =/ 表现站点下所有地址都会发送该Cookie
SameSite 设置该Cookie的同源策略, = none 指示客户端应该禁用Cookie 的同源限制
HttpOnly 指示创建的Cookie是否能通过Javascript访问(该cookie依然存于浏览器上),这里true,表示不能通过Javascript访问该Cookie
从属性定义看,属性值的写法也无懈可击,为什么最后一步请求http://website1.com时未能加载Cookie for website1
?
最后在官方站点搜到这样内容:
“ The SameSite = None parameter causes compatibility problems with clients that implemented the prior 2016 draft standard (for example, iOS 12). See Supporting older browsers in this document; Apps accessed from older browsers which support the 2016 SameSite standard may break when they get a SameSite property with a value of None. Web apps must implement browser detection if they intend to support older browsers
遵守IETF 2016草案的浏览器不认识Samesite= None属性值,会遇到兼容性问题,若站点打算支持这些旧内核浏览器须实现浏览器嗅探。
这个信息让我眼前一亮,赶紧对比故障浏览器内核:
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3314.0 Safari/537.36 SE 2.X MetaSr 1.0
搜狗浏览器的Chrome内核版本65位列不兼容列表。
binggo, 问题定位
修复策略
我们的目的是为兼容这些旧核心浏览器,但是本人不打算打补丁(浏览器嗅探,根据User-Agent屏蔽SameSite=none)
结合站点的同源限制的现状,本站点没有必要显式设置SameSite= None
,可保持Samesite默认值Lax
。
说干就干,修改SameSite属性值,重新k8s部署之后,搜狗浏览器正常单点登陆。
context.Response.Cookies.Append(_options.SsoTgtName, tgt1, new Microsoft.AspNetCore.Http.CookieOptions
{
HttpOnly = true,
SameSite = Microsoft.AspNetCore.Http.SameSiteMode.Lax,
Secure = false,
});
回顾SameSite历史和版本变更
http://ASP.NET Core是在2.0版本开始支持SameSite(IETF 2016草案),http://ASP.NET Core默认将Cookie SameSite设为Lax, 遇到身份验证问题后,大多数SameSite使用被禁用。
IETF 2019标准发布了修复补丁,2019 SameSite草案规定:
- 与2016年草案不向后兼容
- 默认将Cookie SameSite= Lax
- 显式设置SameSite=None时,必须将该Cookie标记为Secure,
None是一个新值
- http://ASP.NET Core 3.1在SameSite枚举值中新增Unspecified,表示不写入SameSite属性值,继承浏览器默认的Cookie策略
- 预定于2020年2月由Chrome默认启用该草案,浏览器需要渐渐迁移到该草案。
就本站单点登陆而言, 同源策略SameSite设置为Lax是合适的,能解决旧内核浏览器不识别SameSite=None丢失Cookie的问题,对常规单点登陆也无碍。
[1] https://docs.microsoft.com/en-us/aspnet/core/security/samesite?view=aspnetcore-2.1#sob
[2] https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/