Nothing stands out from your code. It is very good code. You have changed to gluon/tools.py but I do not think they can be causing this problem.
On Tuesday, 24 July 2012 14:48:16 UTC-5, Massimo Di Pierro wrote: > > I should add that the conflict I mentioned below is not possible unless > there is a proxy in between. That is because the session id includes the > client IP. > > I really do not see how this problem can be possible. Are you sure they > are not playing a prank on you? If they share a facebook page perhaps they > know each other. I have to ask but we will keep investigating the issue > very seriously nevertheless. > > For now I suggest you add this to your code: > > if auth.user: > session.clients = session.clients or [] > if not request.client in session.clients: > session.clients.append(request.client) > if len(session.clients)>1: print auth.user.email, session.clients > > log the output and check how often you have multiple session.clients for > the same email from different network top level domains (xxx.*.*.*) If you > do, email the user and check what is going on with them. > > Massimo > > > > > On Tuesday, 24 July 2012 14:26:35 UTC-5, Massimo Di Pierro wrote: >> >> The only time I have seen something like this was long age. Web2py was >> running on replicated VMs behing a load balancer. If two requests from new >> users arrived within a short time frame (do not remember if a millisecond >> or a second), they were assigned the same session uuid because uuid.uuid4() >> could not discriminate between the VMs. We fixed it by make uuid dependent >> on the os entropy source urandom and initializing it differently on >> different VMs using the IP address. The fix works on linux/unix but not on >> Windows. Replicated windows machine may suffer from this problem still. >> >> What is the web server and configuration in your case? >> Do you know what was the link that caused the problem? >> Which page she was directed too? >> >> massimo >> >> On Tuesday, 24 July 2012 10:18:46 UTC-5, Jonathan Lundell wrote: >>> >>> On 24 Jul 2012, at 6:41 AM, Neil wrote: >>> >>> Good point about trunk. There are some features that I liked and got >>> used to, but nothing essential. >>> >>> I'll try to summarize any relevant settings in the hope that someone can >>> spot something. >>> >>> In 0.py I have: >>> >>> ... >>> settings.login_method = 'local' >>> settings.login_config = '' >>> ... >>> >>> in db.py: >>> >>> ... >>> auth = Auth(db, hmac_key=Auth.get_or_create_key()) >>> crud, service, plugins = Crud(db), Service(), PluginManager() >>> auth.define_tables() >>> db.auth_user.last_name.requires = None >>> auth.settings.actions_disabled.append('register') >>> auth.settings.registration_requires_verification = False >>> auth.settings.registration_requires_approval = True >>> auth.settings.reset_password_requires_verification = False >>> auth.settings.login_next = URL("social_anxiety", "user_main") >>> auth.settings.logout_next = URL("default", "index") >>> ... >>> >>> and in default.py: >>> >>> >>> def index(): >>> session.forget(response) >>> if auth.is_logged_in(): >>> redirect(URL(c='social_anxiety', f='user_main')) >>> else: >>> return dict() >>> >>> def user(): >>> if request.args(0) == 'register': >>> db.auth_user.first_name.comment = '(or an anonymous user name)' >>> elif request.args(0) == 'profile': >>> redirect(URL(c='default', f='user_profile')) >>> >>> return dict(form = auth()) >>> >>> and in layout.html to create the navbar: >>> >>> {{try:}} >>> {{=auth.navbar(referrer_actions=None)}} >>> {{except:pass}} >>> >>> Anything stand out? In particular, anything that would apply one user's >>> session to another user on a different computer? >>> >>> Now that I look at it, "session.forget" in application/default/index >>> seems like a bad idea. I put it in to see if I could speed up the main page >>> and kind of forgot about it... Just removed it. >>> >>> >>> That jumped out at me too, but it's not obvious how it could result in >>> the reported symptom. >>> >>> Does the forget() call affect the is_logged_in() call one way or the >>> other? Even if it did, in order to appear logged in as user X, a browser >>> would have to present a cookie with session id of a user X session. How >>> could that happen? Weird. >>> >>> >>> Neil >>> >>> >>> On Tuesday, July 24, 2012 2:11:25 PM UTC+1, Richard wrote: >>>> >>>> For sure using trunk is not very safe in production environnement, not >>>> because it not secure, but because sometimes things brake when new >>>> features >>>> are added. If you don't need edge feature, better to stick with stable. >>>> >>>> For the problem you describe, I think if you show us the way you >>>> activate auth could help. I mean it is not just a matter of using >>>> decorator... >>>> >>>> I am not the best one to help you fix this issue, but if you give us >>>> more information like what's in you db.py and all the auth setting you >>>> set, >>>> I am sure there is more knowledge users that will be kind and will help. >>>> >>>> Richard >>>> >>>> >>>> >>>> On Tue, Jul 24, 2012 at 8:18 AM, Neil: >>>> >>>>> I just heard from someone who had never been to my site before. When >>>>> she visited (on her phone), it was already logged on as another user. >>>>> This >>>>> other user (she told me his name) is located on the other side of the >>>>> world, and may or may not have logged out. I'm rather worried - she was >>>>> accessing functions decorated with @auth.requires_login() without even >>>>> having an account, let alone logging in! Once she clicked "logout" she >>>>> was >>>>> no longer able to access any user pages. >>>>> >>>>> I understand this will be tough to debug with so little information. >>>>> Furthermore, I've never observed this behaviour personally. However, it's >>>>> concerning enough that I thought I'd see if anyone else >>>>> has experienced such a thing. If not, any ideas how such a thing could >>>>> even >>>>> happen? >>>>> >>>>> I'm using trunk - I suppose I should roll back to stable? >>>>> >>>>> Neil >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> -- >>> >>> >>> >>> >>> >>> >>> --