On Mar 16, 2011, at 11:01 AM, Corne wrote:
>
> Yes, I have a working solution now.
> Thanks for all the help :)
The fix is in the trunk, and will be in the next stable version.
Yes, I have a working solution now.
Thanks for all the help :)
On Mar 15, 2011, at 12:17 PM, Corne wrote:
>
>> When you set your own session_id, does the corresponding session file always
>> exist?
> Yes, it does. I'm sure..
>
>> If that's not an issue, you could try setting response.session_new = False
>> before calling session.connect
> I already tried t
> When you set your own session_id, does the corresponding session file always
> exist?
Yes, it does. I'm sure..
> If that's not an issue, you could try setting response.session_new = False
> before calling session.connect
I already tried that, and then it does work.
The problem we are running i
On Mar 15, 2011, at 11:33 AM, Massimo Di Pierro wrote:
>
> Right now the session is a combination of client ip and a uuid. The
> uuid prevents session hijacking.
>
> The ip serves two purposes:
> - the server can find expired sessions more easily
> - the apps the reject sessions coming from wrong
Right now the session is a combination of client ip and a uuid. The
uuid prevents session hijacking.
The ip serves two purposes:
- the server can find expired sessions more easily
- the apps the reject sessions coming from wrong ip thus further
protecting against hijacking.
On Mar 15, 11:55 am, J
On Mar 15, 2011, at 7:15 AM, Corne wrote:
>
> We (again) looked deeper into what is really happening; and it is yet
> different.
>
> What we ran into is the following:
> We tried to set a session_id our self based on information in the url,
> which in this case resulted in calling the session con
We (again) looked deeper into what is really happening; and it is yet
different.
What we ran into is the following:
We tried to set a session_id our self based on information in the url,
which in this case resulted in calling the session connect code (where
it went wrong) twice per request.
In ca
On Mar 14, 2011, at 8:55 AM, Corne wrote:
>
> We've looked into the problem a bit deeper.. There is a problem but
> it's different than what was in the first post.
>
> The problem seems to be in the locking of the session file:
> Two processes/requests open the same session file for write and thu
We've looked into the problem a bit deeper.. There is a problem but
it's different than what was in the first post.
The problem seems to be in the locking of the session file:
Two processes/requests open the same session file for write and thus
get a handle on it
One request gets the portalocker
Which code are you using. Jonathan and I agree that Corne's patch in
this thread does not lock the session.
web2py does lock sessions unless you do session._unlock(request)
On Mar 14, 6:17 am, KMax wrote:
> I have similar behavior. Same long time generating page opened same
> time in few tabs gi
I have similar behavior. Same long time generating page opened same
time in few tabs give me some tabs with erased(overwrited?) session
file and as a result login page. No exception or error.
Is using session in db solve this issue?
On 12 мар, 00:06, ron_m wrote:
> You should only get a portaloc
You should only get a portalocker.LockException if the no blocking option is
set on the lock attempt which it is not the case in the original web2py
code.
However, the exception handler inside portalocker.lock will re-raise any
exception if it is not IOError for Errno 11
It would be very helpf
On Mar 11, 2011, at 5:13 AM, Massimo Di Pierro wrote:
>
> This is a strange behavior of open. Which linux version? Anyway, I
> will test your solution, it seems the right one.
No. The second open unlocks the file (presumably because f is closed with f
gets rebound) and it's not getting locked ag
I do not believe the file is locked using the code above because the
second open closes the previous file pointer and unlocks the file. Can
you show the traceback of the problem you are having?
On Mar 11, 3:30 am, Corne wrote:
> Hello,
>
> We were running into the following:
>
> (os: Linux - Apac
> This is a strange behavior of open. Which linux version?
Slackware 13.0
(with kernel 2.6.33.3)
This is a strange behavior of open. Which linux version? Anyway, I
will test your solution, it seems the right one.
Massimo
On Mar 11, 3:30 am, Corne wrote:
> Hello,
>
> We were running into the following:
>
> (os: Linux - Apache with mod_wsgi)
>
> We have client code which does a number of requ
17 matches
Mail list logo
