`HttpCookie.toSetCookieString()` doesn't honor expiration date of cookies

[mdemaso]

There seems to be a flaw in the creation of the expiration part of HttpCookie.toSetCookieString().

HttpCookie.maxAge is the amount of time from the moment the cookie is created to when it should expire. This duration isn't being translated to the string being generated by toSetCookieString(). The string has the time at which that method is called plus the maxAge. This means every time I call the function I get a different "expiry" value, leading to the chance that I actually send a cookie that has expired after syncing with a WebView.

Unfortunately, HttpCookie doesn't allow access to the whenCreated value to make calculating the true expiry date possible, no matter when you happen to call the method HttpCookie.toSetCookieString().

I have resolved this in a similar library by creating my own "Cookie" class and using it to generate an HttpCookie or okhttp(2|3).Cookie when needed. This new class contains the maxAge and a created timestamp that is accessible.

[gotev]

Yes, your analysis is correct. Never observed such a case, because I use cookies as OTPs, invoking an API to generate cookies everytime before opening the webviews. For me it's just a way to make the webview know I'm authenticated.

The case you described should however fall in one of those cases:

• remotely revoked session, login necessary
• invalid or no session, login necessary

The second case is the same as when you are calling the webpage without any cookie or with a regularly expired cookie, even when you implement it like you described. So yes, current implementation is flaky in some cases near the effective expiration and can surely be made better, but from a functional point of view

Server should always be the single source of truth for authentication.

Could you describe your use case in detail?