Re: [web2py] User accessed site without logging in
Sorry for bothering, solved On Wednesday, December 5, 2012 9:28:54 AM UTC+2, Aurelijus Useckas wrote: 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),
Re: [web2py] User accessed site without logging in
And what was the problem? On Wed, Dec 5, 2012 at 6:12 AM, Aurelijus Useckas aurelijus.usec...@gmail.com wrote: Sorry for bothering, solved On Wednesday, December 5, 2012 9:28:54 AM UTC+2, Aurelijus Useckas wrote: 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 =
Re: [web2py] User accessed site without logging in
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
Re: [web2py] User accessed site without logging in
yes i use current in modules, when i get back to testing this and have some details worth reporting i'll open a ticket. this is all that i have right now: https://groups.google.com/forum/?fromgroupspli=1#!topic/web2py/aaG7YK7fddg thanks, cfh On 7/24/12 14:55 , Massimo Di Pierro wrote: Is there an open issue about this? If not, can you open one with more details? On Tuesday, 24 July 2012 16:31:52 UTC-5, howesc wrote: one other scenario.. i reported a few months back that running web2py on GAE with python2.7 and multi-threading had odd behaviors with the globals (request, response, session). i have yet tracked down the issues i was having (might have been a coding error on my part).but if you are using GAE + multithreading i'd be interested to know that. cfh On Tuesday, July 24, 2012 1:26:21 PM UTC-7, 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
Re: [web2py] User accessed site without logging in
Added validation for request.client in trunk On Wednesday, 25 July 2012 16:29:45 UTC-5, Massimo Di Pierro wrote: Hello Neil, thank you for this thread and for how you handled the issue. This was a tricky one to debug and a very important issue for the community. We can all rejoice this is a uwsgi issue and not a web2py one. There is nothing web2py can do if the web server injects the wrong headers but I will add some client_addr validation and raise HTTP(xxx) if the client_addr is unknown. massimo On Wednesday, 25 July 2012 11:54:07 UTC-5, Neil wrote: I got to the point where I could reproduce this locally using incognito mode. Looks like it is a known uwsgi bug that was just patched 3 days ago: http://stackoverflow.com/questions/11598935/uwsgi-resends-headers-in-async-mode To anyone else using a recent version of uwsgi - you might want to turn off async, or you could get some very undesirable behaviour (and angry users)! On Wednesday, July 25, 2012 2:49:48 PM UTC+1, Massimo Di Pierro wrote: The author of the post below says: These are 2 distinct clients. I opened an incognito session, confirmed that no cookie was sent in the headers, and the uwsgi log shows that it received the same HTTP_COOKIE. This could very much be the problem. It would definitively cause the behavior you see. I still do not understand what uwsgi is doing. Is it proxing cookies? And what does facebooks and iDevices have to do with this? I have a theory. the problems where from iDevices. Probably they are going over phone networks. Perhaps they have IPv6 addresses. Perhaps uWSGI gets confused by this or by some other weird parameter in the HTTP_HEADER coming from these devices. One symptom is that it assigns cliend_addr = unknown as we have seen before. It is possible that uWSGI by default caches cookies from the same client addr. I do not understand why it would do that but it could be. Perhaps uWSGI is as fast as it is because it skips some proper header parsing. Massimo --
Re: [web2py] User accessed site without logging in
Quick update: -* I had another report of this happening during the night*. I have disabled everything past the main page until I can get to the bottom of this - Waiting for more information from the user. i.e. to get their platform and the link they clicked - I know that the user they were erroneously logged in as had been active on the site around the time. - I rolled back to stable before this happened, so it isn't a problem with trunk - Using webfaction/nginx/uwsgi (ver 1.2.4) Neil On Tuesday, July 24, 2012 11:53:26 PM UTC+1, Craig Younkins wrote: What is the deployment configuration? What wsgi server and what web server? Craig Younkins On Tue, Jul 24, 2012 at 5:55 PM, Massimo Di Pierro wrote: Is there an open issue about this? If not, can you open one with more details? On Tuesday, 24 July 2012 16:31:52 UTC-5, howesc wrote: one other scenario.. i reported a few months back that running web2py on GAE with python2.7 and multi-threading had odd behaviors with the globals (request, response, session). i have yet tracked down the issues i was having (might have been a coding error on my part).but if you are using GAE + multithreading i'd be interested to know that. cfh On Tuesday, July 24, 2012 1:26:21 PM UTC-7, 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.htmlhttp://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-urandomhttp://community.webfaction.com/questions/9333/importerror-cannot-import-name-urandom http://stackoverflow.com/**questions/10776797/error-when-** importing-wsgihandler-with-**djangohttp://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.
Re: [web2py] User accessed site without logging in
Incidentally, no problems importing urandom. On Wednesday, July 25, 2012 8:10:53 AM UTC+1, Neil wrote: Issue #2 === There is a bug with may prevent urandom from working: http://community.webfaction.**com/questions/9333/** importerror-cannot-import-**name-urandomhttp://community.webfaction.com/questions/9333/importerror-cannot-import-name-urandom http://stackoverflow.com/**questions/10776797/error-when-** importing-wsgihandler-with-**djangohttp://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? --
Re: [web2py] User accessed site without logging in
Perhaps a coincidence, but: User 1 - Accessed my site through a Facebook link on iPhone User 2 - Accessed my site through a Facebook link on iPad Does FB do anything strange with links to external sites that could cause the request.client to be unknown? I've accessed my site through the FB link using my Android mobile, and no noticeable problems. On Wednesday, July 25, 2012 9:27:36 AM UTC+1, Neil wrote: Incidentally, no problems importing urandom. On Wednesday, July 25, 2012 8:10:53 AM UTC+1, Neil wrote: Issue #2 === There is a bug with may prevent urandom from working: http://community.webfaction.**com/questions/9333/** importerror-cannot-import-**name-urandomhttp://community.webfaction.com/questions/9333/importerror-cannot-import-name-urandom http://stackoverflow.com/**questions/10776797/error-when-** importing-wsgihandler-with-**djangohttp://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? --
Re: [web2py] User accessed site without logging in
Could this be related? http://stackoverflow.com/questions/11092444/nginx-keeps-passing-the-same-http-cookie-to-uwsgi It's a little beyond me, but I notice that HTTP_REFERER is facebook in both cases, and they are also using nginx+uwsgi. On Wednesday, July 25, 2012 12:07:26 PM UTC+1, Neil wrote: Perhaps a coincidence, but: User 1 - Accessed my site through a Facebook link on iPhone User 2 - Accessed my site through a Facebook link on iPad Does FB do anything strange with links to external sites that could cause the request.client to be unknown? I've accessed my site through the FB link using my Android mobile, and no noticeable problems. On Wednesday, July 25, 2012 9:27:36 AM UTC+1, Neil wrote: Incidentally, no problems importing urandom. On Wednesday, July 25, 2012 8:10:53 AM UTC+1, Neil wrote: Issue #2 === There is a bug with may prevent urandom from working: http://community.webfaction.**com/questions/9333/** importerror-cannot-import-**name-urandomhttp://community.webfaction.com/questions/9333/importerror-cannot-import-name-urandom http://stackoverflow.com/**questions/10776797/error-when-** importing-wsgihandler-with-**djangohttp://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? --
Re: [web2py] User accessed site without logging in
The author of the post below says: These are 2 distinct clients. I opened an incognito session, confirmed that no cookie was sent in the headers, and the uwsgi log shows that it received the same HTTP_COOKIE. This could very much be the problem. It would definitively cause the behavior you see. I still do not understand what uwsgi is doing. Is it proxing cookies? And what does facebooks and iDevices have to do with this? I have a theory. the problems where from iDevices. Probably they are going over phone networks. Perhaps they have IPv6 addresses. Perhaps uWSGI gets confused by this or by some other weird parameter in the HTTP_HEADER coming from these devices. One symptom is that it assigns cliend_addr = unknown as we have seen before. It is possible that uWSGI by default caches cookies from the same client addr. I do not understand why it would do that but it could be. Perhaps uWSGI is as fast as it is because it skips some proper header parsing. Massimo On Wednesday, 25 July 2012 07:23:46 UTC-5, Neil wrote: Could this be related? http://stackoverflow.com/questions/11092444/nginx-keeps-passing-the-same-http-cookie-to-uwsgi It's a little beyond me, but I notice that HTTP_REFERER is facebook in both cases, and they are also using nginx+uwsgi. On Wednesday, July 25, 2012 12:07:26 PM UTC+1, Neil wrote: Perhaps a coincidence, but: User 1 - Accessed my site through a Facebook link on iPhone User 2 - Accessed my site through a Facebook link on iPad Does FB do anything strange with links to external sites that could cause the request.client to be unknown? I've accessed my site through the FB link using my Android mobile, and no noticeable problems. On Wednesday, July 25, 2012 9:27:36 AM UTC+1, Neil wrote: Incidentally, no problems importing urandom. On Wednesday, July 25, 2012 8:10:53 AM UTC+1, Neil wrote: Issue #2 === There is a bug with may prevent urandom from working: http://community.webfaction.**com/questions/9333/** importerror-cannot-import-**name-urandomhttp://community.webfaction.com/questions/9333/importerror-cannot-import-name-urandom http://stackoverflow.com/**questions/10776797/error-when-** importing-wsgihandler-with-**djangohttp://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? --
Re: [web2py] User accessed site without logging in
I got to the point where I could reproduce this locally using incognito mode. Looks like it is a known uwsgi bug that was just patched 3 days ago: http://stackoverflow.com/questions/11598935/uwsgi-resends-headers-in-async-mode To anyone else using a recent version of uwsgi - you might want to turn off async, or you could get some very undesirable behaviour (and angry users)! On Wednesday, July 25, 2012 2:49:48 PM UTC+1, Massimo Di Pierro wrote: The author of the post below says: These are 2 distinct clients. I opened an incognito session, confirmed that no cookie was sent in the headers, and the uwsgi log shows that it received the same HTTP_COOKIE. This could very much be the problem. It would definitively cause the behavior you see. I still do not understand what uwsgi is doing. Is it proxing cookies? And what does facebooks and iDevices have to do with this? I have a theory. the problems where from iDevices. Probably they are going over phone networks. Perhaps they have IPv6 addresses. Perhaps uWSGI gets confused by this or by some other weird parameter in the HTTP_HEADER coming from these devices. One symptom is that it assigns cliend_addr = unknown as we have seen before. It is possible that uWSGI by default caches cookies from the same client addr. I do not understand why it would do that but it could be. Perhaps uWSGI is as fast as it is because it skips some proper header parsing. Massimo --
Re: [web2py] User accessed site without logging in
Il giorno 25/lug/2012, alle ore 18:54, Neil ha scritto: I got to the point where I could reproduce this locally using incognito mode. Looks like it is a known uwsgi bug that was just patched 3 days ago: http://stackoverflow.com/questions/11598935/uwsgi-resends-headers-in-async-mode You can get the updated stable-branch from here: http://projects.unbit.it/hg/uwsgi-1.2 (the maintainance release will be tomorrow) but generally you will get not advantages in using plain async mode with web2py (probably that's why the bug popped up so late) -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it --
Re: [web2py] User accessed site without logging in
Hello Neil, thank you for this thread and for how you handled the issue. This was a tricky one to debug and a very important issue for the community. We can all rejoice this is a uwsgi issue and not a web2py one. There is nothing web2py can do if the web server injects the wrong headers but I will add some client_addr validation and raise HTTP(xxx) if the client_addr is unknown. massimo On Wednesday, 25 July 2012 11:54:07 UTC-5, Neil wrote: I got to the point where I could reproduce this locally using incognito mode. Looks like it is a known uwsgi bug that was just patched 3 days ago: http://stackoverflow.com/questions/11598935/uwsgi-resends-headers-in-async-mode To anyone else using a recent version of uwsgi - you might want to turn off async, or you could get some very undesirable behaviour (and angry users)! On Wednesday, July 25, 2012 2:49:48 PM UTC+1, Massimo Di Pierro wrote: The author of the post below says: These are 2 distinct clients. I opened an incognito session, confirmed that no cookie was sent in the headers, and the uwsgi log shows that it received the same HTTP_COOKIE. This could very much be the problem. It would definitively cause the behavior you see. I still do not understand what uwsgi is doing. Is it proxing cookies? And what does facebooks and iDevices have to do with this? I have a theory. the problems where from iDevices. Probably they are going over phone networks. Perhaps they have IPv6 addresses. Perhaps uWSGI gets confused by this or by some other weird parameter in the HTTP_HEADER coming from these devices. One symptom is that it assigns cliend_addr = unknown as we have seen before. It is possible that uWSGI by default caches cookies from the same client addr. I do not understand why it would do that but it could be. Perhaps uWSGI is as fast as it is because it skips some proper header parsing. Massimo --
Re: [web2py] User accessed site without logging in
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 yager.n...@gmail.com wrote: 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 -- --
Re: [web2py] User accessed site without logging in
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.
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
--
--
Re: [web2py] User accessed site without logging in
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
--
--
--
Re: [web2py] User accessed site without logging in
Can you look for any evidence in your server logs or auth_event table? Don't forget that sometimes trunk is actually more secure because fixes don't get back-ported to stable. Seems like we might need to see more code (ah, Massimo asked for such). What does this do? settings.login_method = 'local' --
Re: [web2py] User accessed site without logging in
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
--
--
--
Re: [web2py] User accessed site without logging in
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
Re: [web2py] User accessed site without logging in
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
Re: [web2py] User accessed site without logging in
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
Re: [web2py] User accessed site without logging in
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)
Re: [web2py] User accessed site without logging in
one other scenario.. i reported a few months back that running web2py on GAE with python2.7 and multi-threading had odd behaviors with the globals (request, response, session). i have yet tracked down the issues i was having (might have been a coding error on my part).but if you are using GAE + multithreading i'd be interested to know that. cfh On Tuesday, July 24, 2012 1:26:21 PM UTC-7, 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,
Re: [web2py] User accessed site without logging in
Are you using current in modules? On Tuesday, 24 July 2012 16:31:52 UTC-5, howesc wrote: one other scenario.. i reported a few months back that running web2py on GAE with python2.7 and multi-threading had odd behaviors with the globals (request, response, session). i have yet tracked down the issues i was having (might have been a coding error on my part).but if you are using GAE + multithreading i'd be interested to know that. cfh On Tuesday, July 24, 2012 1:26:21 PM UTC-7, 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: ...
Re: [web2py] User accessed site without logging in
Is there an open issue about this? If not, can you open one with more details? On Tuesday, 24 July 2012 16:31:52 UTC-5, howesc wrote: one other scenario.. i reported a few months back that running web2py on GAE with python2.7 and multi-threading had odd behaviors with the globals (request, response, session). i have yet tracked down the issues i was having (might have been a coding error on my part).but if you are using GAE + multithreading i'd be interested to know that. cfh On Tuesday, July 24, 2012 1:26:21 PM UTC-7, 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
Re: [web2py] User accessed site without logging in
What is the deployment configuration? What wsgi server and what web server? Craig Younkins On Tue, Jul 24, 2012 at 5:55 PM, Massimo Di Pierro massimo.dipie...@gmail.com wrote: Is there an open issue about this? If not, can you open one with more details? On Tuesday, 24 July 2012 16:31:52 UTC-5, howesc wrote: one other scenario.. i reported a few months back that running web2py on GAE with python2.7 and multi-threading had odd behaviors with the globals (request, response, session). i have yet tracked down the issues i was having (might have been a coding error on my part).but if you are using GAE + multithreading i'd be interested to know that. cfh On Tuesday, July 24, 2012 1:26:21 PM UTC-7, 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.htmlhttp://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-urandomhttp://community.webfaction.com/questions/9333/importerror-cannot-import-name-urandom http://stackoverflow.com/**questions/10776797/error-when-** importing-wsgihandler-with-**djangohttp://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
