And what was the problem?
On Wed, Dec 5, 2012 at 6:12 AM, Aurelijus Useckas
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
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
>
>
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 t
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/?fromgroups&pli=1#!topic/web2py/aaG7YK7fddg
thanks,
cfh
On 7/24/12 14:55 , Massimo Di Pierro wrote:
Is
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 th
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
This is very useful information - I was always unsure about using async.
Thanks a lot!
On Wednesday, July 25, 2012 6:49:39 PM UTC+1, Roberto De Ioris wrote:
>
>
> You can get the updated stable-branch from here:
>
> http://projects.unbit.it/hg/uwsgi-1.2
>
> (the maintainance release will be tom
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
>
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
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 se
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 wrot
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
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-
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 erro
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
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
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 tr
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 us
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 po
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
-.
This means that one of th
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 i
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 perha
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()
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 = 'l
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
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:
...
aut
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
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
28 matches
Mail list logo
