Hi Massimo, One of my users gets an error: Bad Request (request.client=unknown)
Does it have anything to do with your update? Can I change the requirement somewhere? Thank you On Tuesday, July 24, 2012 11:26:21 PM UTC+3, Massimo Di Pierro wrote: > > Perhaps it would be safe to block access to the site if request.client is > "unknown". > I think we should change web2py to block access to any web2py app if > request.client does not validate as an IP address. > > Massimo > > On Tuesday, 24 July 2012 15:24:06 UTC-5, Massimo Di Pierro wrote: >> >> Here is a possible cause of the problem although I am not sure. >> There are two possible issues which may conspire to create this problem. >> >> Issue #1 >> ======= >> >> There is a session file in the app you sent me called: >> >> unknown-c4571a37... >> >> session files should be >> >> <ip>-..... >> >> This means that one of the HEADERS http_x_forwarded_for or remote_addr >> has a value "unknown". >> >> A first google search retuned: >> http://nixforums.org/about154671-Hacking-X-Forwarded-For.html >> which opens the possibility the the web server, in your case nginx, is >> not finding the client ip address (how is that possible) and setting it to >> unknown. This should never happen. The client_addr is a required field for >> WSGI. >> >> This could be the result of a hacking attempt but it would required both >> parties doing the hacking for the sessions to be mixed up. >> >> Issue #2 >> ======= >> >> There is a bug with may prevent urandom from working: >> >> >> http://community.webfaction.com/questions/9333/importerror-cannot-import-name-urandom >> >> http://stackoverflow.com/questions/10776797/error-when-importing-wsgihandler-with-django >> >> Can you check if you can import urandom on your version of python on >> webfaction? >> >> >> It is therefore theoretically possible that, given the concurrency model >> of nginx, if two users visit the site very close to each other, with >> urandom missing, both declaring the same incorrect client ip (unknown), >> they get assigned the same session id. This is because web2py has no way of >> distinguishing the two users and lacks a proper random number generator. >> >> TODO: >> >> 1) check if you can import urandom >> 2) try understand how it possible to have an "unkown" client_addr in the >> http headers. >> >> My google search returned nothing about 2. Has anybody ever seen this >> before? >> Please let us know. >> >> >> >> >> >> >> >> >> >> On Tuesday, 24 July 2012 14:50:04 UTC-5, Massimo Di Pierro wrote: >>> >>> 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 >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> On Tuesday, 24 July 2012 14:50:04 UTC-5, Massimo Di Pierro wrote: >>> >>> 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 >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> --
