My original suggestion would still work--run a cron job every minute
(or so) that finds all of the sessions that have an expiration date
since the last time the script was run--delete those, then log an
entry in your audit table. Seems pretty simple to me, and I can't see
any reason why it wouldn
On Mar 17, 10:45 pm, Jacob Kaplan-Moss
wrote:
> On Tue, Mar 17, 2009 at 8:55 PM, Huuuze wrote:
> > 7. Django detects the missing cookie
>
> I think this is where you're getting hung up. Django doesn't "detect"
> a "missing" cookie; Django sees a request from a browser that doesn't
> include a c
On Tue, Mar 17, 2009 at 8:55 PM, Huuuze wrote:
> 7. Django detects the missing cookie
I think this is where you're getting hung up. Django doesn't "detect"
a "missing" cookie; Django sees a request from a browser that doesn't
include a cookie. Nothing's missing; it's just a new browser without
On Tue, 2009-03-17 at 18:55 -0700, Huuuze wrote:
> Malcolm, I believe you and appreciate your advice, but you need to
> ease up. You're getting hung up on semantics. In this instance, I'm
> simply differentiating between a user clicking a link that says
> "Logout" (a.k.a, a manual logout) versus
Malcolm, I believe you and appreciate your advice, but you need to
ease up. You're getting hung up on semantics. In this instance, I'm
simply differentiating between a user clicking a link that says
"Logout" (a.k.a, a manual logout) versus Django detecting the lack of
a session cookie and redire
On Tue, 2009-03-17 at 18:32 -0700, Huuuze wrote:
[...]
> As soon as the session expires, Django
> updates the records in the django.sessions table. As such, the only
> unique identifier for the user, "session_key", is overwritten.
This isn't what happens when a session expires at all. Django d
On Wed, 2009-03-18 at 01:28 +, Paulo Köch wrote:
> > Calling logout(), as the original poster requested doesn't achieve
> > anything (it does nothing). If it did do something, it would still be a
> > bad idea to call it, because the user could have already logged in again
> > and logging them
Yes, it does generate new session_id. The user has essentially told
Django to expire the session, which in turn results in a new session
key.
I'm starting to agree with Malcolm. Outside of an elaborate solution,
this one may not be possible. As soon as the session expires, Django
updates the r
> Calling logout(), as the original poster requested doesn't achieve
> anything (it does nothing). If it did do something, it would still be a
> bad idea to call it, because the user could have already logged in again
> and logging them out would be unfortunate.
Doesn't this generate a new sessio
On Wed, 2009-03-18 at 01:17 +, Paulo Köch wrote:
[...]
> Based on this, I can't see why a simple custom cron job inspecting the
> pickled session data (assuming the user_id is in the session) before
> purging old session would not suffice. Care to elaborate?
I think you've arrived back at the
On Wed, Mar 18, 2009 at 01:06, Malcolm Tredinnick
wrote:
> There's no guarantee that the same session
> will go to the same process (not to mention that the processes will stop
> and start over time).
>
> If you're going to do something like this, it has to be external from
> the web-process life
On Wed, 2009-03-18 at 00:55 +, Paulo Köch wrote:
> Coder speaks louder. HTH.
>
> #Pseudo code. Not tested nor proven.
> class TimeoutTimerPool(object):
> """A pool that tracks a set of users and their active session.
> Tipically used as a singleton."""
> from threading import Timer
> de
Argh! Code in emails sucks. Besides, there was a typo in the previous
email. See http://dpaste.com/15848/
Cheers,
Paulo Köch
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this grou
Coder speaks louder. HTH.
#Pseudo code. Not tested nor proven.
class TimeoutTimerPool(object):
"""A pool that tracks a set of users and their active session.
Tipically used as a singleton."""
from threading import Timer
def __init__(self):
self.pool = {}
def expiration_handler(self, s
On Tue, 2009-03-17 at 23:26 +, Paulo Köch wrote:
> My previous idea was to maintain a Timer pool based on session ids.
> Every time a request with a session hits your server, you reset the
> Timer object associated with it. If a user logs out, you cancel the
> respective timer. If a timer trig
My previous idea was to maintain a Timer pool based on session ids.
Every time a request with a session hits your server, you reset the
Timer object associated with it. If a user logs out, you cancel the
respective timer. If a timer triggers, it's a timeout.
But, we can try a simpler approach. As
Paulo, thank you for the link, but I don't see how that will help. To
help articulate the problem, here is a post I included on
StackOverflow.com:
>> I would like to audit when a user has experienced an idle timeout in my
>> Django application. In other words, if the user's session cookie's
>>
Taking the lead from
http://www.artfulcode.net/articles/threading-django/ I would sugest
you use a Timer object
(http://www.python.org/doc/2.5.2/lib/timer-objects.html).
DISCLAIMER: Careful! I haven't tested this! A Timer object uses a
thread internally. Be careful with synchronization and relate
Care to elaborate with some sample code?
On Mar 16, 9:12 pm, Paulo Köch wrote:
> A background sleeper (as opposed to worker) that would fire a signal
> upon timer expiration seems like a nice mechanism.
>
> Cheers,
> Paulo Köch
>
> On Tue, Mar 17, 2009 at 01:04, Jeff FW wrote:
>
> > When you sa
And it's clearly a feature request. Bug implies defect in
implementation, not formulation.
Cheers.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us
A background sleeper (as opposed to worker) that would fire a signal
upon timer expiration seems like a nice mechanism.
Cheers,
Paulo Köch
On Tue, Mar 17, 2009 at 01:04, Jeff FW wrote:
>
> When you say "audit"--what do you mean? By that, I mean, what do you
> plan to do with the data? Do yo
When you say "audit"--what do you mean? By that, I mean, what do you
plan to do with the data? Do you need to know the second someone
times out, or can you check later?
If you need to know immediately, I think you may need to do something
terrible with JavaScript. If not, or you can at least w
On Mon, Mar 16, 2009 at 8:56 PM, Huuuze wrote:
>
> Jeff (and Jacob)...
>
> I appreciate your responses and I stand corrected. With that being
> said, are either of you (or anyone reading this) aware of a method
> that would allow me to track idle session timeouts? I'd like to audit
> when a use
Jeff (and Jacob)...
I appreciate your responses and I stand corrected. With that being
said, are either of you (or anyone reading this) aware of a method
that would allow me to track idle session timeouts? I'd like to audit
when a user has been logged out due to a timeout.
Huuuze
On Mar 16, 7
It's not a bug. When a cookie expires, the browser stops sending it
with its requests--therefore, there is *no* way for Django to know
that the cookie (and therefore, the session) has expired. There is no
"timeout" happening on the server side, so the session can't get
cleared out. Hence, why t
On Mon, Mar 16, 2009 at 4:46 PM, Huuuze wrote:
> Does anyone else agree with my viewpoints on this matter? If so,
> please post your comments in the ticket.
Actually, the right way to get your viewpoint heard is to take the
matter to the django-developers mailing list, where topics related to
D
I opened the following ticket which was unceremoniously closed by a
committer:
http://code.djangoproject.com/ticket/10518
Here is the text from the ticket:
>> I have set the SESSION_COOKIE_AGE value in my settings.py file to expire
>> sessions after 1 hour. Django successfully logs the user out
27 matches
Mail list logo