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
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>
>>
> --
>
>
>
>
>
>
>
--
