> 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
