Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#5028 closed defect (fixed)

"remeber me" does not keep the user logged in

Reported by: aseerel4c26 Owned by: rails-dev@…
Priority: minor Milestone:
Component: website Version:
Keywords: cookies Cc:

Description

(based on Sabra Sharaya's report at help.osm.org)

How do I get http://www.openstreetmap.org to keep me logged in? I check the "Remember Me" box every time I log in. If I go back to the site soon after that, I will still be logged in. If I close the browser, I'll be logged out again.

I have cookies disabled in Firebox but I have an exception set for openstreetmap.org to allow cookies indefinitely.

Tested with FF25 and chromium 30 on Linux.

Obeservation: Looking in the cookie list shows that the cookie is still there after a restart (having a expiration date of roughly one month later). However, as soon as I go to www.openstreetmap.org it is replaced by a new (session lifetime only) cookie.

Change History (9)

comment:1 Changed 5 years ago by aseerel4c26

edit I am talking of the _osm_session cookie above.

comment:2 Changed 5 years ago by aseerel4c26

edit I do not remember that it did work in the past.

comment:3 Changed 5 years ago by aseerel4c26

Summary: "remeber me" keeps the user logged in"remeber me" does not keep the user logged in

comment:4 Changed 5 years ago by Tom Hughes

I've looked into this at some length this week and I'm really not able to reproduce the problem as described here.

That is to say that if I login, then restart my browser, my sessions survive just fine.

Note that you will need the _osm_username cookie as well as _osm_session, but the _osm_username cookies should have a long expiry and survive browser restarts.

What is true is that if you leave it a few days (regardless of whether you restart the browser) then the session is likely to expire anyway, as the lifetime is not only covered by the 28 day life of the session cookie, but also by the amount of space available for the session store on the server - unused sessions will tend to age out of that store.

Looking at the numbers it seems that as we've grown the typical time before an unused session ages out on the server has now fallen to only about 2-3 days, so last night I increased the amount of memory available in the session store considerably, which should extend that time to several weeks.

I'd be interested in knowing if that seems to have improved things - note that any sessions started before last night will have been lost when the memory limit was increased.

comment:5 Changed 5 years ago by aseerel4c26

Thank you Tom!

  • With my usual firefox profile: _osm_username is just a session cookie and hence not there anymore after a browser restart.
  • With a firefox in another user account with a relatively clean profile it is instead a cookie valid until 15 Nov 2033 ... hence existent after a restart. And: the "remember me" checkbox works.
  • In my usual chromium profile: _osm_username is valid until 15. November 2033. As expected it is still there after a restart, and remember me works.

Interesting....

Testing again with my usual firefox profile but in safe-mode (addons disabled):

  • username is NOT session-only. Consequently username and session cookie still there after a restart. Remeber me works as expected.
  • restarted firefox with all addons active again: cookies still there, rememberme works.
  • deleted _osm cookies, relogin with rememberme, again _osm_username does only get created as a session cookie. Hmm! Some addon sooomehow interfering with the username cookie creation?!
  • switched off noscript's "secure cookie management". Now it works as on the clean firefox profile.
  • tested: installed noscript in the clean-ish firefox profile on the other user account: remember works. Switched on the secure cookie management: username is a session cookie, rememberme does not work.

So, some interpretations: sorry, apparently I did my first test in Chromium wrong, somehow. The other user (Sabra Sharaya) also has that noscript setting active or hit the low session store problem on the server (although "If I close the browser" does not sound like that). I had asked "If it works for someone please comment there" in the question on the help site - could have several possibilities why no one has commented here.

Why does that happen? Not sure... I have read a bit more about that feature in its FAQ. I still do not understand why we see this behaviour. However, I can see in the log that noscript in fact toogles the cookies "secure" flag on and off again (as expained in the FAQ).

What to do?

  • Is there anything OSM can do? I do not really know (except offering a full https session, good idea anyway). And: It would be less confusion if there would not be two cookies used for authentication but just one, but this is a very very very minor issue.
  • To me it currently seems that it is a noscript bug (changing the cookie lifetime without saying so in the FAQ for this feature). Not sure why the same is not done for the _osm_session cookie. I will try to monitor that and maybe report as bug against noscript.

Workaround: add www.openstreetmap.org to the exception list for the secure cookie handling. That also works - so you can keep the secure cookie feature of noscript enabled for other sites. :-)

Tom, do you got any further ideas?

comment:6 Changed 5 years ago by Tom Hughes

Thanks for figuring that out... I'm guessing I already had an _osm_username cookie when they introduced that feature to NoScript? and hence I never saw this because it's so long lived.

I don't think there's a good solution, other than allowing https more widely, which we're already working on, or dropping the _osm_username cookie which, strictly speaking, shouldn't be needed.

The history of this is that back when we upgraded to rails 3.1 there was an odd issue going on, which I never got to the bottom of, where sessions were getting mixed up and people were appearing to be logged in as other people, which obviously wasn't good. So I added a double check in 5bc3054/rails which stores the username in an additional cookie and cross checks it against the session on future requests.

Having said that, the logs don't seem to show it actually being triggered these days, other than a few misfires when somebody changes their username, so maybe we can get rid of it now.

comment:7 Changed 5 years ago by aseerel4c26

So you can reproduce it (after deleting your _osm cookies) by using that (apparently non-default) NoScript? feature? Would be good to know.

Uh, thanks for the in-depth _osm_username explanation. Well, I do not know if it is good to remove it. But if you can tell from the logs that it is not needed anymore, you could try to remove it. As you said, it would be bad/strange if it really would be needed (session-security-wise). Could well be that the problem with NoScript? vanishes then.

comment:8 Changed 5 years ago by Tom Hughes

Resolution: fixed
Status: newclosed

I removed the _osm_username stuff this morning, so this should be fixed now.

comment:9 Changed 5 years ago by aseerel4c26

Thank you, Tom!

Works as expected. Tested with FF25 (with NoScript? and the secure setting) and chromium 30 on Linux. The session cookie is valid for 1 month, as before. And NoScript? secures and unsecures it (upon detecting the move HTTPS->HTTP).

In case someone is interested - 41e45ba seems to be the changeset removing the _osm_username cookie.

Note: See TracTickets for help on using tickets.