On Thu, 2007-03-15 at 02:30 +, Uros Trebec wrote:
> Hi everyone,
>
> I am the maintainer of "full-history" branch and I am currently trying
> to bring it up to date.
>
> I am trying to merge current trunk to the branch and the only way to
> do that successfully was to use "svnmerge" tool.
>
On Wed, 2007-03-14 at 22:44 -0700, ak wrote:
> Guys
> The only thing I don't understand at the moment is: everyone
> understands that current implementation of ORM together with current
> implementation of sessions table doesn't allow to force insert and
> throw exception if it fails. So I can sta
Guys
The only thing I don't understand at the moment is: everyone
understands that current implementation of ORM together with current
implementation of sessions table doesn't allow to force insert and
throw exception if it fails. So I can state this as a special case.
Every framework has limitati
On Thu, 2007-03-15 at 07:04 +0530, Arvind Singh wrote:
[...]
> What I don't understand is: Why the developers don't do the correct
> thing by providing separate insert() and update() in addition to
> save() ? All it requires is a trivial refactoring and actually
> simplifies the code (also clarify
On 3/14/07, James Bennett <[EMAIL PROTECTED]> wrote:
> 1. Manually seeding the RNG with a value unique to the server process,
> or to the request, would move the probability of key collision closer
> to what it "should" be, thus dramatically reducing the problem.
Do we really need to re-seed the
Malcolm Tredinnick wrote:
> It's a discussion worth having in a clam manner in another thread.
Did anyone else picture mollusks having a conversation when they read
that? ;-)
--
Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to t
Hi everyone,
I am the maintainer of "full-history" branch and I am currently trying
to bring it up to date.
I am trying to merge current trunk to the branch and the only way to
do that successfully was to use "svnmerge" tool.
Now, the merge apparently went well, without any conflicts, so I woul
> 1. Manually seeding the RNG with a value unique to the server process,
> or to the request, would move the probability of key collision closer
> to what it "should" be, thus dramatically reducing the problem.
Problem is reduced... but still remains.
> 2. Changing the session framework's behavi
On 3/14/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> If you have multiple processes which initialize their random
> module at exactly the same system time (how granular is it?, you'll get the
> same seed and therefore the same sequence of pseudorandom numbers in
> python2.3
>
> In python2.4, t
Simon G. wrote:
> #3307 - Add BCC to mail framework.
> I've renamed this ticket from what it used to be. This originally had
> two issues - one which overlapped with #1541, and the other this BCC
> request. There's a patch here with adds a parameter to send_mass_mail
> to suppress the recipi
> On 14 mrt, 01:40, "Honza Kr=E1l" <[EMAIL PROTECTED]> wrote:
>
> for this use DateField( default=3Dmodels.LazyDate() ), it will do
> exactly what you want: supply a default value of NOW() when no
> timestamp is given.
>
> It seems redundant to replicate this with the auto_* stuff, those are
> me
On 3/14/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> 2) James has suggested that the answer is, perhaps, better seeding. I
> really don't think that this is an issue. Regardless of the seed,
> there is still a mathematical chance that a collision will occur.
This is true, but given the rang
ak wrote:
> Ivan, although reseeding still not guarantees that there may be no
> duplicates as INSERTing does, isn't it ?
Yeah... I actually don't object to your approach at all, I'm just
guessing why random numbers could become... uhm... not that random.
--~--~-~--~~~--
Man, there's been a lot of movement in this thread.
I'd like to just throw out a few comments.
1) The current session framework unquestionably needs some attention.
The way in which sessions are being generated isn't terribly
efficient, and can certainly lead to collisions.
2) James has sugge
On 14 Mar, 08:51, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> I hadn't realised that existing cursors pulled everything over at once
> -- I would have "guessed" (based on no information other than "that's
> the way I would think of doing it") that they would pull a chunk of
> results each ti
On Wed, Mar 14, Ivan Sagalaev wrote:
>
> Michael Radziej wrote:
> > Beginning with python2.4, the seed also uses os.urandom() when available, so
> > it starts to get safer.
>
> Uhm... But it still happens only once on first module import. So it's
> not safer at all.
If you have multiple proce
> On 14 mrt, 01:40, "Honza Kr=E1l" <[EMAIL PROTECTED]> wrote:
>
> for this use DateField( default=3Dmodels.LazyDate() ), it will do
> exactly what you want: supply a default value of NOW() when no
> timestamp is given.
>
> It seems redundant to replicate this with the auto_* stuff, those are
> mea
> On 14 mrt, 01:40, "Honza Král" <[EMAIL PROTECTED]> wrote:
>
> for this use DateField( default=models.LazyDate() ), it will do
> exactly what you want: supply a default value of NOW() when no
> timestamp is given.
>
> It seems redundant to replicate this with the auto_* stuff, those are
> meant
Ivan, although reseeding still not guarantees that there may be no
duplicates as INSERTing does, isn't it ?
And insert needs to be done only once at session start and is
performed ANYWAY at session start. The difference in my way is that
insert is done when new session is created and in django's w
Michael Radziej wrote:
> Beginning with python2.4, the seed also uses os.urandom() when available, so
> it starts to get safer.
Uhm... But it still happens only once on first module import. So it's
not safer at all.
> I'm not sure whether it's a good idea to add periodic reseeding.
Why not? I
Henrique Ser, you lost the fact that we are using lighttpd, not
apache, but our django works as preforked fastcgi.
I can only say that i will NEVER use a potentially vulnerable session
implementation where any not logged in user may get superuser's
permission, even if a chance for this to happen a
As I said, we restart our django fastcgi server a few times per a day.
I think it is more related to:
> Beginning with python2.4, the seed also uses os.urandom() when available, so
> it starts to get safer.
and our app runs under xen domU debian installation so may be there's
something related
Hello all,
I am quite new at django and I've been trying to get all the info I can
by, amongst other means, reading through django-dev and django-users. I
don't remember in which I read this but fastcgi, the way it is designed,
doesn't work well with threads. The actual details escape me but I
Ticket: http://code.djangoproject.com/ticket/3600
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe fro
> 2. I have an ethernet connection @home and I sometimes log in to our
> private web apps from home. Any 'c00l hacker' is able to scan network
> traffic, get my session id and use it to join to my session too just
> because there is absolutely no checking who uses session. We added ip
> checking
On Wed, Mar 14, Ivan Sagalaev wrote:
> I've just recalled a case... I was using Django's randomly generated
> passwords and it worked fine under mod_python. Then I switched to
> FastCGI and from some moment *all* passwords started being generated
> absolutely equal. The thing was that mod_pyth
Btw, we use Debian with python 2.4 too
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this grou
Michael Radziej wrote:
> But something else must go wrong in your case, as the chance to get the
> same session ids should be so tiny that you really shouldn't reports
> from your users. Comments say that the random number generator is
> seeded when the server process starts, and it's seeded with
Michael, I really don't know how would it be possible, I only know the
following:
1. My production web server restarts a few times per day. Sometimes
twice (in a really short period ie 2-3 minutes)
2. I got a report from _new_ user that he received e-mail with login
and pass, clicked to link and b
Hi Anton,
ak schrieb:
>> so it doesn't get us any real improvement in security
>
> James, there is a concept of 'fool proof'. Real hackers may do many
> things. But current model allows even 10 year old kids to be hackers.
> This is just against them. There is no ability to protect all sites
> w
30 matches
Mail list logo
