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.
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/
On Tue, Jul 31, 2012 at 5:11 PM, Uncle Cheese <aaroncarl...@gmail.com>wrote:
> 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.
> --
> 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 silverstripe-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> silverstripe-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/silverstripe-dev?hl=en.
> 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.
> --
> 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 silverstripe-dev@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
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.
On 1/08/2012, at 5:25 AM, Gary Greenberg <gigt...@gmail.com> wrote:
> On 31 Jul 2012, at 18:11, Uncle Cheese <aaroncarl...@gmail.com> wrote:
>> 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.
>> --
>> 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 silverstripe-dev@googlegroups.com.
>> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To post to this group, send email to silverstripe-dev@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
(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.
On 1/08/2012, at 10:56 AM, Simon J Welsh <welsh.si...@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.
> > 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
On Wed, Aug 1, 2012 at 12:28 AM, Marcus Nyeholt <nyeh...@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.
> 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
> --
> You received this message because you are subscribed to the Google Groups
> "SilverStripe Core Development" group.
> To post to this group, send email to silverstripe-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> silverstripe-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/silverstripe-dev?hl=en.
On Wednesday, 1 August 2012 04:11:05 UTC+12, Uncle Cheese wrote:
> 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.
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.
On 1/08/2012, at 7:25 PM, matt clegg <cleggm...@gmail.com> wrote:
> On Wed, Aug 1, 2012 at 12:28 AM, Marcus Nyeholt <nyeh...@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.
>> 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
>> --
>> You received this message because you are subscribed to the Google Groups
>> "SilverStripe Core Development" group.
>> To post to this group, send email to silverstripe-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> silverstripe-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/silverstripe-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To post to this group, send email to silverstripe-dev@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
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.
On 23/08/2012, at 9:27 AM, Simon J Welsh <welsh.si...@gmail.com> wrote:
> 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.
> On 1/08/2012, at 7:25 PM, matt clegg <cleggm...@gmail.com> wrote:
>> On Wed, Aug 1, 2012 at 12:28 AM, Marcus Nyeholt <nyeh...@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.
>>> 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
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "SilverStripe Core Development" group.
>>> To post to this group, send email to silverstripe-dev@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> silverstripe-dev+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/silverstripe-dev?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
>> To post to this group, send email to silverstripe-dev@googlegroups.com.
>> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To post to this group, send email to silverstripe-dev@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
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.
On 23/08/2012, at 7:37 PM, Ingo Schommer <i...@silverstripe.com> wrote:
> 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.
> On 23/08/2012, at 9:27 AM, Simon J Welsh <welsh.si...@gmail.com> wrote:
>> 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.
>> On 1/08/2012, at 7:25 PM, matt clegg <cleggm...@gmail.com> wrote:
>>> On Wed, Aug 1, 2012 at 12:28 AM, Marcus Nyeholt <nyeh...@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.
>>>> 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
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "SilverStripe Core Development" group.
>>>> To post to this group, send email to silverstripe-dev@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> silverstripe-dev+unsubscribe@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/silverstripe-dev?hl=en.
>>> -- >>> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
>>> To post to this group, send email to silverstripe-dev@googlegroups.com.
>>> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
>>> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
>> To post to this group, send email to silverstripe-dev@googlegroups.com.
>> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To post to this group, send email to silverstripe-dev@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
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? :)
On 23/08/2012, at 10:10 AM, Simon J Welsh <welsh.si...@gmail.com> wrote:
> 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.
> On 23/08/2012, at 7:37 PM, Ingo Schommer <i...@silverstripe.com> wrote:
>> 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.
>> On 23/08/2012, at 9:27 AM, Simon J Welsh <welsh.si...@gmail.com> wrote:
>>> 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.
>>> On 1/08/2012, at 7:25 PM, matt clegg <cleggm...@gmail.com> wrote:
>>>> On Wed, Aug 1, 2012 at 12:28 AM, Marcus Nyeholt <nyeh...@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.
>>>>> 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
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups
>>>>> "SilverStripe Core Development" group.
>>>>> To post to this group, send email to silverstripe-dev@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> silverstripe-dev+unsubscribe@googlegroups.com.
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/silverstripe-dev?hl=en.
>>>> -- >>>> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
>>>> To post to this group, send email to silverstripe-dev@googlegroups.com.
>>>> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
>>>> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
>>> -- >>> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
>>> To post to this group, send email to silverstripe-dev@googlegroups.com.
>>> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
>>> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
>> To post to this group, send email to silverstripe-dev@googlegroups.com.
>> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To post to this group, send email to silverstripe-dev@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
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.
On Thursday, 23 August 2012 19:27:31 UTC+12, Simon wrote:
> 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/7806and 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.
> On 1/08/2012, at 7:25 PM, matt clegg <cleg...@gmail.com <javascript:>> > wrote:
> > On Wed, Aug 1, 2012 at 12:28 AM, Marcus Nyeholt <nye...@gmail.com<javascript:>> > 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.
> >> 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
> >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "SilverStripe Core Development" group. > >> To post to this group, send email to silverst...@googlegroups.com<javascript:>.
> > -- > > You received this message because you are subscribed to the Google > Groups "SilverStripe Core Development" group. > > To post to this group, send email to silverst...@googlegroups.com<javascript:>.
