Crates.io: Does not stay signed in

[stpettersens]

I've noticed while using Crates.io recently that the log in sessions are very flakey.

I log in in multiple times and each time my session lasts less than a minute or so before I have to log in again. So much so that Github actually requested I reauthorize as the log in rate is suspicious.

Is this just me or are other people having this problem recently.

Cheers,

Sam.

[carols10cents]

I would be interested in hearing from people if this is the case-- while working on crates.io, I do strange things like clearing cookies, switching servers, switching logins, etc so I'm not a typical user. I haven't noticed this though, but I'll try and keep an eye on it now.

Thank you for the report, I'm sorry this is happening and I hope we can figure it out soon! 🎏 🔜

[carols10cents]

Oh also do you have a sense of how recently is recently? I know this might be hard to remember, but like in the last week? The last month? The last three months? That might help us narrow it down.

[sgrif]

Random data point -- I am not currently logged into crates.io upon visiting, and there's no reason I should not be. I'm not sure when the last time I logged in on this machine was (my expectation is that session expiry would be one year, it was probably in the last 3 months or so)

[stpettersens]

@carols10cents: Oh of today. Couple hours ago using Vivaldi 1.10.847.48. Noticed it doesn't seem to be happening in Firefox. I'll try Chrome, if it's a browser problem I think Chrome should be the same as Vivaldi.

[carols10cents]

@stpettersens so yesterday was fine? That is, when was the last time you had visited crates.io when login was behaving as expected? Thank you for the additional information!

@sgrif just in case this is relevant, what browser are you using?

[carols10cents]

Mostly for my own records, here are the last bunch of deploys to productions by date and commit:

v264 Deploy ce47e8c4 2017/07/14 18:46:51 -0400
v263 Deploy 111c9a86 2017/07/12 15:55:31 -0400
v262 Deploy d5f9cdd2 2017/07/12 09:08:39 -0400
v261 Deploy 38527370 2017/07/11 16:19:50 -0400
v260 Deploy 00251a74 2017/07/09 15:07:20 -0400
v259 Deploy 70b5481f 2017/07/08 14:37:30 -0400
v258 Deploy 1dd1c9d2 2017/07/07 14:06:42 -0400
v257 Deploy 1f5d4307 2017/07/03 10:33:03 -0400
v256 Deploy 086249c4 2017/07/01 20:05:35 -0400
v255 Deploy f94a74d7 2017/06/29 16:59:56 -0400
v254 Deploy 1f080497 2017/06/27 19:12:39 -0400

[sgrif]

@carols10cents Chrome

[stpettersens]

@carols10cents: I think its probably a Chromium related issue because
Vivaldi and Chrome seem to be affected. I noticed the problem first
yesterday. Everything was fine the times I used Crates before, which was
probably a few months back. Don't typically need to sign in.

On 17 Jul 2017 13:46, "Sean Griffin" [e-mail] wrote:

@carols10cents https://github.com/carols10cents Chrome

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/crates.io/issues/888#issuecomment-315745437,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVsGUf-kX7xp9ZFs70heDtfPKWyq6dRks5sO1e7gaJpZM4OZZ1A
.

[jtgeibel]

Here is the behavior that I am seeing. I can log in and navigate within the app with no issues. If if refresh the page or manually navigate (alt+d, enter) then I'm redirected to the root and shown "Please log in to proceed".

The manual page load appears to be sending a valid cargo_session cookie in the request. In fact, the cookie's value never changes even after logging back in. I'm on Firefox 54 on Linux.

[sgrif]

Just to chime in, I can confirm the issue. I am not logged in today when I was yesterday

[carols10cents]

I'm not able to reproduce the behavior @jtgeibel is seeing by refreshing the main page when logged in nevermind i totally am, idk what i was doing differently. I'm very consistently able to reproduce if I'm on https://crates.io/me. That is, this is how I can reproduce:

• visit crates.io (i am logged out despite not remembering doing so)
• log in
• click on "account settings" to go to crates.io/me, page loads fine
• click reload in the browser, i get logged out

This is happening for me in firefox 54.0.1, so it's not a chromium-only problem :(

Another data point: @natboehm isn't able to reproduce this-- she can reload /me without getting logged out! HOWEVER, if she opens a private window to start a new session, then follows the reproduction steps, she is able to reproduce this.

So I currently suspect that she has an older "good" cookie??? and the rest of us have newer "bad" cookies????

[stpettersens]

@carols10cents: Does seem to be a cookie problem.

On 20 July 2017 at 17:12, Carol (Nichols || Goulding) <
[email protected]> wrote:

I'm not able to reproduce the behavior @jtgeibel
https://github.com/jtgeibel is seeing by refreshing the main page when
logged in, but I am able to reproduce if I'm on https://crates.io/me.
That is, this is how I can reproduce:

• visit crates.io (i am logged out despite not remembering doing so)
• log in
• click on "account settings" to go to crates.io/me, page loads fine
• click reload in the browser, i get logged out

This is happening for me in firefox 54.0.1, so it's not a chromium-only
problem :(

Another data point: @natboehm https://github.com/natboehm isn't able
to reproduce this-- she can reload /me without getting logged out! HOWEVER,
if she opens a private window to start a new session, then follows the
reproduction steps, she is able to reproduce this.

So I currently suspect that she has an older "good" cookie??? and the rest
of us have newer "bad" cookies????

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/crates.io/issues/888#issuecomment-316753248,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVsGZmN3AUOtiI47DVtcBPUEaGl7ca4ks5sP3yKgaJpZM4OZZ1A
.

[sgrif]

This actually looks like it 100% is a cookie problem. We are not setting any expiration on the cookie when it's sent to the browser, so it defaults to a session cookie. We should be setting a year long expiry.

[carols10cents]

ok well there's also this change https://github.com/conduit-rust/conduit-cookie/pull/4 that will invalidate everyone's cookies as well, so before we fix everyone's cookies i think i want to make that change. will try to get a version bump over there

[carols10cents]

We are not setting any expiration on the cookie when it's sent to the browser, so it defaults to a session cookie. We should be setting a year long expiry.

I'm confused, shouldn't a session cookie only log you out when you close your browser? Why does a page reload invalidate the session?

[stpettersens]

That's true. Something's funky.

On 22 Jul 2017 16:28, "Carol (Nichols || Goulding)" <
[email protected]> wrote:

We are not setting any expiration on the cookie when it's sent to the
browser, so it defaults to a session cookie. We should be setting a year
long expiry.

I'm confused, shouldn't a session cookie only log you out when you close
your browser? Why does a page reload invalidate the session?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/crates.io/issues/888#issuecomment-317190871,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVsGTUnqVYSxVGOFWiaHXYi_T_nZ-zOks5sQhU4gaJpZM4OZZ1A
.

[carols10cents]

ugggghhhh I can't get reproduce locally, not even if i set up a hostname that's not localhost/127.0.0.1

[carols10cents]

!!! i can't reproduce on https://staging-crates-io.herokuapp.com either!!! curiouser and curiouser...

[sgrif]

It should generally not clear on a page reload, but it's highly dependent on your browser's settings.

[jtgeibel]

I found some steps that allow me to reproduce this on my machine. It seems to be tied to the /me route. Once I trigger the issue, it is a problem for me until I clear the browser cache.

1. Clear your browser cache (or try on staging if you aren't currently seeing the issue there)
2. Login
3. Reload the page on any routes other than /me. After the reload I am still logged in.
4. Navigate to /me and reload the page. I am logged out and now reloads on all routes cause me to logout. This can be fixed by clearing the browser cache again.

One other minor thing I noticed is that when things are working if I refresh the /dashboard page, my name and avatar are there on the initial render. For / and /crates I'm briefly shown the log in link which is quickly replaced with my name and avatar.

[jtgeibel]

I think I've figured something out here! I'm only seeing this weird behavior with exactly /me. I have no issues with /me/crates, /me/following, or even /me/; that is until I visit /me for the first time after flushing the browser's cache.

It's a bit confusing because this route exists on both the frontend and the backend. Additionally, on the backend a normal request for html content will serve the index.html content created by ember at build time, while a request for json will return an object with the user's {id, login, email, name, avatar, and url} fields.

I'm thinking that navigating directly to /me results in an HTML response which is then cached. As the ember application boots it does a GET /me with Accept: application/json but sees the cached response which is not json data. From this point on the frontend can no longer obtain the user's information from the backend. When it tries to request this data it sees the cached html response without sending a request.

It looks like we should be setting Vary: Accept for at least this route. Probably even something like Vary: Accept, Accept-Encoding, Cookie. We may want to define different policies for api requests and static assets.

I also agree that we should be setting a year long expiration date on the cargo_session cookie.

[carols10cents]

oh geez. thank you so much for doing this research @jtgeibel!!!

[joshtriplett]

I'm seeing this issue as well, with current Firefox on today's crates.io. Logging in works, then some subset of navigations leads me to become logged out. I can confirm that going to /me reliably reproduces this problem.