[ic] {Spam?} Re: Re: long-lived sessions/carts?

[Grant]

>> > >> I'm currently expiring sessions after 2 days:
>> > >>
>> > >> find /cat/tmp -type f -mtime +2 | xargs --no-run-if-empty rm && find
>> > >> /cat/tmp -depth -type d -empty -mtime +2 | xargs --no-run-if-empty
>> > >> rmdir && find /cat/session -type f -mtime +2 | xargs --no-run-if-empty
>> > >> rm && find /cat/session -depth -type d -empty -mtime +2 | xargs
>> > >> --no-run-if-empty rmdir
>> > >>
>> > >> Has anyone tried waiting much longer than that?  Maybe 30, 60, or even
>> > >> 90 days?  When I'm shopping online, I've noticed it's nice to add
>> > >> something to my cart and come back much later to find the item still
>> > >> in there without having to create an account.
>> > >>
>> > >> - Grant
>> > >
>> > > It's obviously a tradeoff with security.  Personally, I don't like to
>> > > keep session open for more than a day.  In some cases where I give users
>> > > the ability to edit content, I don't keep the sessions for more than a
>> > > couple hours.   Maybe when they save a cart, you can send them an email
>> > > with a unique key that will expire for that longer time?
>> > > Rick
>> >
>> > Hi Rick, so security is a consideration because an attacker could
>> > guess IP addresses and session keys in order to gain access to someone
>> > else's session?  Is there anything sensitive kept in a
>> > typical/standard IC session besides shipping and billing address?
>> >
>> > - Grant
>> >
>>
>> Well, address info alone makes me cringe, and It is pretty easy to
>> hijack a session in many environments.  I also give users access to do
>> allot of things within their session including
>> creating/modifying/sharing content on the site, messaging other users,
>> etc...  I look at a "session" as only a first line of defense for a very
>> short time and kick people out ASAP.  If they want to save anything,
>> share anything, or create content, I give them a link to URL with a key,
>> or require them to log in.  Since creating an account is a pain in the
>> ass, You don't have to require them to log in if you just give them a
>> link to a URL for a given resource with a unique key... I usually hash
>> the session for that key and expire it much later (days or weeks etc...)
>> Rick
>>
>>
>
> One example is a site where I made a HTML5 feature where people could
> upload a photo of their face, and try on glasses.  If they want, they
> can also share their photo on social networks without logging in to IC.
> In order to do this, I used a hash of their session as part of the URL
> of that private photo.  This way, they could share the resource with
> others without logging in, and without worrying about session hijack.
> Rick

That makes a lot of sense for that sort of thing, but the unique URL
requirement isn't ideal for this since shoppers can drift in and out
of a store over any period of time without referring to a particular
URL.  I think saving the cart contents in a cookie or setting up cart
contents to expire much later than sensitive session information would
be ideal?

- Grant