[prev in list] [next in list] [prev in thread] [next in thread] 

List:       interchange-users
Subject:    Re: [ic] {Spam?} Re: Re: long-lived sessions/carts?
From:       Grant <emailgrant () gmail ! com>
Date:       2012-02-22 0:49:33
Message-ID: CAN0CFw2v+nh_fT+QOdTfwHAfDJaFTyzANw6spbFPL4yfVtmwxg () mail ! gmail ! com
[Download RAW message or body]

>> > >> 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-em=
pty
>> > >> rm && find /cat/session -depth -type d -empty -mtime +2 | xargs
>> > >> --no-run-if-empty rmdir
>> > >>
>> > >> Has anyone tried waiting much longer than that? =A0Maybe 30, 60, or=
 even
>> > >> 90 days? =A0When 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. =A0Personally, I don't like=
 to
>> > > keep session open for more than a day. =A0In some cases where I give=
 users
>> > > the ability to edit content, I don't keep the sessions for more than=
 a
>> > > couple hours. =A0 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? =A0Is 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. =A0I also give users access to do
>> allot of things within their session including
>> creating/modifying/sharing content on the site, messaging other users,
>> etc... =A0I look at a "session" as only a first line of defense for a ve=
ry
>> short time and kick people out ASAP. =A0If 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. =A0Since 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. =A0If 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. =A0This 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

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users
[prev in list] [next in list] [prev in thread] [next in thread]