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