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

-- 



Reply via email to