Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69367 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81662 invoked from network); 27 Sep 2013 00:46:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Sep 2013 00:46:46 -0000 Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222) Received: from [173.1.104.101] ([173.1.104.101:58876] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 08/B8-37010-475D4425 for ; Thu, 26 Sep 2013 20:46:45 -0400 Received: from localhost ([216.220.114.66]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id MJV39442 for ; Thu, 26 Sep 2013 17:46:42 -0700 Date: Thu, 26 Sep 2013 20:45:26 -0400 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <32311738.20130926204526@cypressintegrated.com> To: Yasuo Ohgaki In-Reply-To: References: <1417591323.20130926185752@cypressintegrated.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) > 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. -- S.