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
>
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
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
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
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:
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
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
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
> > 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
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
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
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
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.
> 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 =
>
> 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
>
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
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
>
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
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
> 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
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
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
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
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
> 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
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
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
32 matches
Mail list logo
