On Jul 8, 5:27 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Increasing
> some value from 32 bits to 64 bits is only changing some probabilities;
> it's not actually solving the problem, just moving the goalposts to make
> it harder to score an own goal. The rest of the conversation should
>
On Tue, 2008-07-08 at 19:27 +1000, Malcolm Tredinnick wrote:
[...]
> It's almost like we need some kind of ticket tracking system so that
> these things don't get lost and people won't start threads saying "look
> at mine! look at mine!" Oh, wait ... we do have one of those. :-(
Sorry. That was
On Tue, 2008-07-08 at 10:30 +0400, Ivan Sagalaev wrote:
> Malcolm Tredinnick wrote:
> > The rest of the conversation should
> > proceed on the assumption that the bug about creating unique database
> > entries will be fixed first.
>
> Now I think that the problem is only exists if one uses
> no
Malcolm Tredinnick wrote:
> The rest of the conversation should
> proceed on the assumption that the bug about creating unique database
> entries will be fixed first.
Now I think that the problem is only exists if one uses
non-transactional DB setup. In this case
due to race conditions one of th
On Mon, 2008-07-07 at 10:09 -0700, digitalxero wrote:
[...]
> The issue may actually be with the get_or_create() method of blocking
> collisions since if it generates a duplicate id it just grabs that
> data from the table and runs with it (I think), but whatever the
> actual cause of the issue t
Thus, looks there are two problems -- collisions happen too often on
32-bit machines (fixed by my patch) and db session backend doesn't
handle them properly (no fix so far).
As for the latter -- Malcolm, you were about to add a clear
distinction between INSERT and UPDATE to .save() in
http://grou
On Mon, Jul 7, 2008 at 12:12 PM, digitalxero <[EMAIL PROTECTED]> wrote:
>
> On Jul 7, 11:09 am, digitalxero <[EMAIL PROTECTED]> wrote:
>> *Adding this info to the ticket as well
>
> Well Trac decided I was spam and wouldn't let me post the data
Log in to trac.
See discussion here:
http://groups.g
On Jul 7, 11:09 am, digitalxero <[EMAIL PROTECTED]> wrote:
> *Adding this info to the ticket as well
Well Trac decided I was spam and wouldn't let me post the data
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"D
As one of the people experiencing issues with the session collisions I
will attempt to explain how it manifests and my setup.
My server is a shared host, running Apache, python2.5 and Django is
configured though fast-cgi (My host wont let me use mod-python). The
way it seems to work is a new thre
On Jul 7, 6:32 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
>
> That comment has no bearing.
>
> (1) We pick a random session key.
> (2) We save it to the database, where it should be unique, otherwise an
> error is raised.
> (3) We use that session key to pass back to the user.
>
> At this
On Mon, 2008-07-07 at 08:28 -0700, mrts wrote:
> > > Due to the birthday paradox, sqrt(n) is roughly the number you need to
> > > have a 50% collision chance when picking items at random from an
> > > inexhaustible set of n items. (0, sys.maxint - 1) is currently the
> > > random range. On 32-bit
> > Due to the birthday paradox, sqrt(n) is roughly the number you need to
> > have a 50% collision chance when picking items at random from an
> > inexhaustible set of n items. (0, sys.maxint - 1) is currently the
> > random range. On 32-bit platforms the collision bound is thus quite
> > low as
On Jul 7, 5:00 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 7, 2008 at 8:48 AM, mrts <[EMAIL PROTECTED]> wrote:
> > I'd like to get some feedback for the following major tickets
> > regarding sessions, all of which are in scope for 1.0.
>
> I don't really know a nice way of s
On Mon, Jul 7, 2008 at 8:48 AM, mrts <[EMAIL PROTECTED]> wrote:
> I'd like to get some feedback for the following major tickets
> regarding sessions, all of which are in scope for 1.0.
I don't really know a nice way of saying this, so I'll trust you to
understand that I don't mean to be a dick.
On Mon, 2008-07-07 at 06:48 -0700, mrts wrote:
> I'd like to get some feedback for the following major tickets
> regarding sessions, all of which are in scope for 1.0.
>
> 1) Session key collisions: http://code.djangoproject.com/ticket/1180
>
> Due to the birthday paradox, sqrt(n) is roughly th
I'd like to get some feedback for the following major tickets
regarding sessions, all of which are in scope for 1.0.
1) Session key collisions: http://code.djangoproject.com/ticket/1180
Due to the birthday paradox, sqrt(n) is roughly the number you need to
have a 50% collision chance when pickin
On Tue, Apr 8, 2008 at 4:25 AM, mrts <[EMAIL PROTECTED]> wrote:
>
> On Apr 8, 12:53 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
> > > Agreed, but as previously described, there should be a way to override
> > > the default behaviour and retain session data if needed.
> >
> > No, I d
On Apr 8, 12:53 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> > Agreed, but as previously described, there should be a way to override
> > the default behaviour and retain session data if needed.
>
> No, I don't see any need for this at all. Once you've logged out, the
> session is over. S
If I may point to a new ticket I just created related to sessions and
race conditions
http://code.djangoproject.com/ticket/6984
It fixes a lot of weirdness I was experiencing. It is still not thread
safe though I am not sure that is an issue since in my (limited)
testing there was a one-to-one ma
On Mon, 2008-04-07 at 03:09 -0700, mrts wrote:
> > Realise that I am in agreement with you that logout (and possibly login,
> > I haven't worked through the implications there) should be changed to
> > clear the session by default. There's no strong reason not to do that,
> > since the session is
> def show_foo(request):
> request.session['foo'] = 'bar'
> request.session.delete(request.session._session_key)
> return HttpResponse(request.session['foo'])
>
> In [1]: from django.contrib.sessions.backends.db import SessionStore
> In [2]: s =
> SessionStore(session_key='61a271f29a67
> Realise that I am in agreement with you that logout (and possibly login,
> I haven't worked through the implications there) should be changed to
> clear the session by default. There's no strong reason not to do that,
> since the session is over when logout is called (I'll raise that
> separatel
On Mon, Apr 7, 2008 at 11:28 AM, Malcolm Tredinnick <
[EMAIL PROTECTED]> wrote:
> Realise that I am in agreement with you that logout (and possibly login,
> I haven't worked through the implications there) should be changed to
> clear the session by default. There's no strong reason not to do that
On Sun, 2008-04-06 at 08:21 -0700, mrts wrote:
[...]
> My personal use case:
> -
>
> User sessions are used apart from django.auth.models.User. The
> application logic doesn't fit well with Django auth (auth
> features are not needed and create a minor security risk if an
>
> Session objects is the right place to store all session-related data.
> It's a many-to-one relation to each user. If you want something that's
> one-to-one with a user, that isn't session data and is easy to implement
> via your own model, but I'm not sure it's common enough to have a common
> A
On Sat, 2008-04-05 at 11:31 -0700, mrts wrote:
[...]
> Once Python 2.3/4 support will be dropped, we can start using
> higher-grade hash algorithms from 2.5 hashlib throughout. But
> this is offtopic for current discussion and will not happen in
> the foreseeable future.
It will be a while beyon
Hey mrts,
On Apr 5, 2:31 pm, mrts <[EMAIL PROTECTED]> wrote:
> The cookies are already signed. Session data +
> settings.SECRET_KEY is md5-digested and tampering raises an
> exception. So in that sense the sessions are already secure.
Sorry, I didn't mean "secure" in the sense that someone can al
> Why not write a "secure" session backend? (You would presumably
> also need to require signed cookies for the session.)
The cookies are already signed. Session data +
settings.SECRET_KEY is md5-digested and tampering raises an
exception. So in that sense the sessions are already secure.
Note th
On Apr 4, 4:00 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> No, please post here. I know you want there to be a formal spec
> process, but there isn't. Right now the way we decide things is by
> posting them here, and you need to do the same.
I entirely accept that. The proposal pages a
On Fri, Apr 4, 2008 at 7:19 AM, mrts <[EMAIL PROTECTED]> wrote:
> I started
> http://code.djangoproject.com/wiki/DjangoSpecifications/Contrib/Sessions
> to properly sort this out. Please edit.
No, please post here. I know you want there to be a formal spec
process, but there isn't. Right now t
I started
http://code.djangoproject.com/wiki/DjangoSpecifications/Contrib/Sessions
to properly sort this out. Please edit.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this gr
Mike Axiak said the following:
> Let me reiterate a position that I posted on #6941. After reviewing, I
> actually *don't* think we're all that muddled. A session is
> {{{request.session}}} and is represented by the browser's session.
> Whereas a user is {{{request.user}}} and is completely separa
On Apr 3, 8:23 pm, mrts <[EMAIL PROTECTED]> wrote:
> > After reading through these, I think most of these can be satisfied
> > with the proper session backend. Why not write a "secure" session
> > backend? (You would presumably also need to require signed cookies for
> > the session.) I would be i
> After reading through these, I think most of these can be satisfied
> with the proper session backend. Why not write a "secure" session
> backend? (You would presumably also need to require signed cookies for
> the session.) I would be interested to see what it would look like.
I think a genera
On Apr 3, 4:36 am, mrts <[EMAIL PROTECTED]> wrote:
> Quoting #6941:
> [4:17pm] jacobkm: Also, there's the question of whether the session is
> tied to the browser or to the user -- we're a bit muddled there
> currently.
Let me reiterate a position that I posted on #6941. After reviewing, I
actual
SessionStore is missing a clear() or invalidate() method that will
destroy the session. Is this intentional? If so, why? Cleaning a
session is such a common requirement for session frameworks.
Looking through tickets, I found the following relevant to general
session logic (in no particular order
36 matches
Mail list logo
