maxAge should translate to the max-age directive about cookies HOT 8 CLOSED

Can you please explain the following/show me how to reproduce this? The reason I ask is because the rationale doesn't really make sense to me, as the time zone is included in the expires value, so there wouldn't be time zone confusion.

Date.now causes issues when maxAge is low (a few hours), since it uses the server date, and the client date may be different due to timezones.

from cookies.

Ok, that was my confusion. I was trying to set maxAge in seconds instead of milliseconds and assumed that the problems were coming from this timezone thing. You're right.

But why don't you allow the max-age cookie directive and instead translate it into a fancy expires?

from cookies.

Gotcha, good to hear there doesn't seem to be an issue with the date :) I mean, this was an adopted module, so I cannot speak for the history (and of course changing it would be a breaking change and would need to be evaluated first). AFAIK it uses expires instead because there are still lots of UAs that simply ignore the max-age attribute, and all the ones that do honor max-age also honor expires, so we basically always have to include expires, so what is the purpose of including both? You can get away with only max-age if you are OK with some of your users silently ending up with session-length cookies, which seems too surprising.

Here's also a blog about the two if it helps: http://mrcoles.com/blog/cookies-max-age-vs-expires/

from cookies.

the maxAge argument should indeed translate to max-age and not expires.
The expires argument includes the timezone, but the UA clock might be offset by a couple of hours (incorrect timezone), which would end-up in the following situation:

• UTC is 2018-01-15 10:00 + 00:00
  Client has localtime: 2018-01-15 10:00 - 08:00 (8h in the future)
• Server set cookie with maxAge = 30min
• Server send:
  Set-Cookie: foo=bar; expires=2018-01-15T10:30:00+00:00
• UA immediately expires the cookie
• UA send a new request without cookie.

Sadly incorrect UA clock is a common problem (at least for us), maxAge is a correct option (as the time is calculated relative to UA clock), but this is not an available option in this library.

Hope this makes sense.

from cookies.

Incorrect UA clock is something we also observe quite often, and the root cause if often broken clock sync, not incorrect timezone.

From the link pasted:

Every browser that supports max-age will ignore the expires regardless of it’s value, and likewise, Internet Explorer will ignore the max-age and just use expires.

..indicating that just setting both shouldn't pose a problem. And It's only IE <=8 that doesn't support max-age.

I find it very strange that nobody has brought this up before in a module heavily in use because of eg. Koa.

Edit: Saw the discussion in #94 now, sorry for adding to the confusion. I still think it's a more sane default to send both.

from cookies.

@ruudud I'm happy to accept a PR that just sets both. The other PR was closed without making that change, so you're most welcome to make one! I can make the change as well, but just wanted to put that out there if you wanted to get credit for the work :D

from cookies.

Did a bit of digging now.. Doesn't seem like Google use the max-age directive for any of their cookies when logging in users.

I'm guessing the reason is that they just run a check client-side, comparing with their server clock, and if it's off by too much, warn the user or whatever. Seems like an OK solution if you ask me..

from cookies.

I've made a new PR for this (#107) as I need the ability to be able to use max-age due to differences I am seeing between the server clock and come clients' clocks.

I'm sending both values so this shouldn't cause a problem with any older browsers, I can't see any downside to this. What do we think?

from cookies.