Recently in the project, I stepped on a pit where set-cookie writing failed. It was not easy to climb the pit.

Fault birth:

An ordering business enters payment after submitting an order. When submitting an order, the server will plant a cookie through set-cookie as the ticket certificate to enter payment. Perfectly normal business process, except that since the order page and the payment page are not in the same domain, cookies need to be transferred across domains.Specifically, in response header of order submission request, a cookie named ticket is planted by set-cookie instruction. The cookie is set only to the root domain, and SameSite=None is allowed to cross domains. Can be shared by two secondary domains of the same root domain as the order page and the payment page.

Set-Cookie: ticket=xxxxxxxx; Domain=root.com; Path=/; Secure; HttpOnly; SameSite=None; Secure

Everything was in place, the tests went well, the release went live, and the bugs started appearing online.

Fault Description:

Some Online Android users reported that they could not normally enter the payment process after submitting orders. The server checked logs and quickly identified the cause as lack of tickets.

The problem was successfully replicated using a Vivo 8.1 machine. When replaying, set-cookie instruction exists in response header of order service, setting cookie of ticket, and ticket content is correct. So why don’t return cookies exist?

Failure analysis:

1. It is assumed that cross-domain cookie transmission fails

Check out the HTTP set-cookie document and the SameSite property, which reads,

If SameSite=None, Secure must be declared, and HTTPS is the security protocol, otherwise cookies cannot be written. You might think this is just another “set-cookie fails when SameSite=None” cliche.

Not too! Not too!

Setting SameSite=None in set-cookie declares Secure, and the request is HTTPS. So, check the cookie data table in cookie emanager, which was surprised, the original Cookie emanager did not write this cookie. So this article is going to crawl the pit where set-cookie cannot be planted into cookies.

2. Guess that the WebView intercepted the request and lost the cookie.

Check configuration in the project of WebViewClient. ShouldInterceptRequest () intercept strategy, can intercept page dom request only, will not intercept page request and business resources, and even the dom after the request is intercepted retransmission, The set-cookie information in the Reponse header will also be manually planted into the CookieManager, so it is excluded that the WebView intercepts the request causing the loss of the Response header set-cookie instruction.

3. It is assumed that the cookie writing mechanism of a special model or system version is abnormal

The reason for this conjecture is that only one device was able to reproduce (Vivo 8.1) when we did the reproduction test, while several other devices were normal. And the Android devices that failed were all of the earlier versions, concentrated under Android 8.1. Therefore, chrome search storm is launched to find out whether certain machine & certain system version has special cookie mechanism. Finally in a large number of search search, in the chormium official update log there is such a description of SameSite, found a strong relevant information.

It explicitly states that from Chrome 51 to Chrome 66 (both ends included), these older versions of Chrome will reject cookies with “SameSite = None”, whether or not you set the Secure property.

It is neither a specific model nor a specific system version (there is no corresponding relationship between the system version and the WebView kernel version, but domestic devices cannot independently update the WebView version due to the wall. Basically, the higher the system version, the higher the webView kernel version). But specific chormium versions are not compatible with SameSite=None.

Verification conclusions:

  • Webview kernel versions of reported users were collected and found to be between 51-66 versions, which was verified.
  • Both Android WebView and Chrome browser are based on the Chromium kernel, so there should be problems not only on Android WebView, but also on the corresponding Chrome browser. Download a chrome_65.0.3325.181 version of the Browser (the old version is not available on the chorme website, but you can easily find a way to download it online), and the problem is exactly the same.

Chrome 51 to Chrome 66 cannot write SameSite=None cookie.