cookie的几个属性

1 httpOnly:true 表示禁止客户端读cookie，即只能在服务端读取它
2 SameSite:用来限制第三方 Cookie，从而减少安全风险。

• Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。

Set-Cookie: CookieName=CookieValue; SameSite=Strict;

• Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。
  导航到目标网址的 GET 请求，只包括三种情况：链接，预加载请求，GET 表单。详见下表。

Set-Cookie: CookieName=CookieValue; SameSite=Lax;

• Chrome 计划将Lax变为默认设置。这时，网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。

Set-Cookie: widget_session=abc123; SameSite=None; Secure

需要明确的

• 跨域之后，不能读写cookie,例如a网站的cookie，b网站不能读到
• samesite:none可以让c网站的cookie，由不能的调用方共享修改，例如a网站操作c网站,c网站写自己的cookie，而b网站也操作c网站，这时c网站的cookie里是可以包含a网站的操作内容的

在keycloak中的应用

keycloak中的cookie，它的会话状态使用了SameSite，从而在由一个网站到别一个网站时，如果你已经登录，那这些登录信息会带到另一个网站去，这是由SameSite特性决定的，和开发的程序无关，我们之间使用kc的session通讯

Secure属性说明

Secure属性是说如果一个cookie被设置了Secure=true，那么这个cookie只能用https协议发送给服务器，用http协议是不发送的。换句话说，cookie是在https的情况下创建的，
而且他的Secure=true，那么之后你一直用https访问其他的页面（比如登录之后点击其他子页面），cookie会被发送到服务器，你无需重新登录就可以跳转到其他页面。但是如果这
是你把url改成http协议访问其他页面，你就需要重新登录了，因为这个cookie不能在http协议中发送，事实上，对于samesite属性为None时，因为只有secure为true它才合法，
所以这samesite=None也只能应用在https环境里。

https已经很安全，所以在它里面可以用 Samesite=None;Secure=true

浏览器对samesite和secure的默认值设置不同

• 火狐
  
  火狐这块更加宽松，跨站的cookie,http协议方式也是可以读到的，谷歌是不可以的。