"Remember me" fail

[Uncle Cheese]

I've been using SilverStripe for five years, and not once, on any computer, in any environment, on any version of SS, on any website, has this ever worked full stop. Simply put, it doesn't remember me, or, it may for a short period of time, but not long enough to justify the label "remember me."

It's reproducible on SS.org. I check "remember me" every time I log in.

Anyone else having this issue? I feel like it's misleading to my clients when they click "remember me" and it just.. doesn't.

[matt clegg]

Yes, its never worked for me..

ss.org is also annoying when you want want to reply to a thread and you need to log in but after logging in it take's you to a different page rather then the thread you were looking at.

--

Matt Clegg

--Easiest way to deal with new EU cookie law when your site has google analytics. Just create a link to  http://cookiestatement.eu/

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/RWVwdQLh0OcJ.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Gary Greenberg]

I second that

Sent from my iPhone

[Simon J Welsh]

Remember me works exactly as expected. If you use the same cookie file to access a site, you will be logged in. This only works if you don't log into your account from another computer/browser, as that changes the token associated with the account.

---
Simon Welsh
Admin of http://simon.geek.nz/

[Nicolaas Thiemen Francken - Sunny Side Up]

What I am wondering is 

(a) you are logged in automatically (i.e. you go straight to the admin section) or that it 

(b) it remembers your username and password but you still go via the login screen. 

The (a) scenario does not seem to be happening for me. 

Nicolaas

[Al Twohill]

On 1/08/2012, at 10:56 AM, Simon J Welsh <welsh...@gmail.com> wrote:

> Remember me works exactly as expected. If you use the same cookie file to access a site, you will be logged in. This only works if you don't log into your account from another computer/browser, as that changes the token associated with the account.

Ah, so you're saying that if you check 'Remember me' on one computer then also another, it will only remember the last? That's a bit dumb.

[Marcus Nyeholt]

> Remember me works exactly as expected. If you use the same cookie file to access a site, you will be logged in. This only works if you don't log into your account from another computer/browser, as that changes the token associated with the account.

Ah, so you're saying that if you check 'Remember me' on one computer then also another, it will only remember the last? That's a bit dumb.

 

It has a nice side effect though in that if you forget logout on a 'public' computer but login from your home pc, the 'public' location is no longer able to get into your account. 

The problem with the Remember stuff looks to be fixed in 3.0 - for a long long time though (and it's still the case on 2.4 branch) the autoLogin logic will only work once, after which it will never work again. The problem lies in 

https://github.com/silverstripe/sapphire/blob/2.4/security/Member.php#L401

$member->RememberLoginToken = $generator->generateHash('sha1');
Cookie::set('alc_enc', $member->ID . ':' . $token, 90, null, null, false, true);


wherein the RemeberLoginToken is reset, but the cookie that is set is for the OLD login token (looks like a copy/paste error from logIn()). 


The fix is simple - change $token for $member->RememberLoginToken


$member->RememberLoginToken = $generator->generateHash('sha1');				
Cookie::set('alc_enc', $member->ID . ':' . $member->RememberLoginToken, 90, null, null, false, true);

[matt clegg]

Cool, looks like its fixed in post-2.4 too

https://github.com/silverstripe/sapphire/blob/post-2.4/security/Member.php#L402

[Paul Clarke]

SS.org will be getting a makeover fairly soon with an upgrade to 3.0 so hopefully we can address this issue at the same time.

[Simon J Welsh]

I have created a ticket on Trac for changing this system to allowing many remember me tokens. The ticket's http://open.silverstripe.org/ticket/7806 and I've copied+pasted the description:

The current remember me system stores one token per user, that is either wiped or set on login, and then updated whenever used. While this works, it does mean that as soon as you log in to your account from another browser, or switch out of private browsing, or do anything that changes the cookie store, the token stored in the user's cookies no longer matches the one in the database.

My proposed solution to this is to extract this single field out of Member and into its own DataObject (say MemberRememberToken) that has a has_many relationship with Member. When logging in with remember me enabled, a new MemberRememberToken is created, and its value is used in the cookie.

When falling back to a remember token, Member::autoLogin() will look for a matching MemberRememberToken instead of just a single field. If a matching one is found, the user is logged in and the value of the MemberRememberToken is changed, which is then stored in the cookie again.

On Member::logout(), only the current MemberRememberToken is deleted.

Facebook/Gmail-esque lists of other sessions, browser types and locations can be added on a per site basis, with an extension hooking into populateDefaults()/onBeforeWrite() (depending on if you want the information from when it's created, or every time it changes) storing the UA and IP. I don't see a need for this information to be stored in the core.

[Ingo Schommer]

I'm with Marcus on this one: A single token means users can log out
of other systems "remotely", e.g. after forgetting to sign off from an internet cafe.
While this can be custom-built based on the available data of course,
I think SS core should give users that level of control over their login status (and hence their data).
We could work around this by removing *all* tokens on logout by default,
with a core config option to allow staying logged-in?

Can you review the security system to see if there's anything blocking
you from making it a module? It sounds like a bit of unnecessary bloat in core.

[Simon J Welsh]

The main problem I have with a single token is it makes it a lot easier to sniff, as it can't change (if you allow the use of the single token across multiple machines). Having it change leads to the problem in this thread where people are expecting it to work, then it doesn't because they logged in on another machine.

There are no hooks in Member::currentUserId(), Member::autoLogin(), Member::member_from_autologinhash(), or anything else in the automated login process until after the member has been selected. There is a usable hook in Member::logout() though.

[Ingo Schommer]

In terms of security ("sniffing"), I don't really see a big difference between
having a single and multiple tokens, given they all grant you the same access,
so its enough to obtain a single one. We can tie tokens to some client uniqueness
checks like used browser and OS, but nothing a determined hacker can't circumvent.

On the missing hooks: Maybe that's a good place to start? :)

[Che Van Lawrence]

Interestingly, I've had this happen on a few sites but not ss.org.  Conversely, CHROME seems to need to ask me about my password every time but ss.org seems to remember me fine.