Hi Standord, On Fri, Sep 27, 2013 at 9:45 AM, Sanford Whiteman < swhitemanlistens-softw...@cypressintegrated.com> wrote:
> > When URL based session is used, this feature should be > > disabled as pages are cached by browsers. > > OK, I suppose, but that seems to be an edgier case than what we're > already discussing. > > > BTW, if connection is unstable and an app force user to logout, > > is it going to be a problem? It would depend on message displayed, but > > I guess users think it is due to unstable connection. > > I definitely (!!!) would not think that if an app forced me to log in > again that it had to do with my connection quality unless I had > already decided the connection was practically unusable -- and that > all bets were off as to whether anything would work as expected. > > Even if I intuited the reason and/or was told about it, I would not > accept being logged out of an app because I went into an elevator (to > use Tjerk's point) or through a train tunnel as appropriate. At all. > You're basically adding insult to injury: not only do you have a bad > connection, but you need to always log in. Makes for a very, very bad > user experience. I would hate an app that did that to me... if I > encountered the situation. > > And what I was interrogating is _how common_ such a situation would be > in each developer's real world, predicting it would be different based > on the ecosystem of a particular app + its users. > > For example, my main app is too heavy for most people to use over 3G > connections, period, so they are unlikely to run into the problem with > us because they wouldn't be trying to use the site in the first place. > > Other apps have a lightweight version that is otherwise usable over > slow/sporadic connections and thus its users are more likely to > encounter timeouts, which the app has previously been tolerating. This > why I referred to _the end-user_ (not _PHP users_) being able to turn > such a feature off. Only a site that is 100% sure that it only is > useable over WiFi/WAN/LAN should roll out such a feature without > giving users control, because otherwise you are _ensuring_ your site > won't work on 3G! Why would you do that if it used to work? > > > If mobile apps are native, almost all apps store username/password > > or some credential that automatically reconnect to service. > > Native apps can have different levels of resilience -- we MUST > consider sites that just happen to be accessed from mobile. And in > those cases there can't be any question that being logged out because > you didn't receive the updated id is not acceptable. The question is > only _how often_ you are pissing off users, not _whether_ you will > piss off a user when you do this. > > I also want to know how you deal with the other insult-to-injury that > I mentioned, where logging out someone after a _real_ session hijack > then reveals their credentials to the attacker who's still listening > on the same network. I'm starting to think there are unintended > consequences here that are approaching "considered harmful" levels. I also don't want to disturb end-users too much. The reason why I think unstable connection would not be much problem is lost session ID occurs only when end-users are connected to site _and_ the connection is immediately lost before setting new session ID. Under normal circumstances, entering elevator or tunnel would not loose session ID most likely since lost connection would not loose session ID. When end-users simply lost their connection, IP address wouldn't change. Therefore, session ID wouldn't change. Establishing connection and immediately loosing it might cause lost session ID. To loose session ID, end-users have to send request to server and loose connection _before_ they receive new session ID. I'm supposing this happens most unlikely. I might be too optimistic, though. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
