On Nov 26, 3:37 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
>If you're as concerned with security as it
> sounds like you are, you might look at SecurID.[1]
>
> -Gul
>
> [1]http://en.wikipedia.org/wiki/SecurID
After thinking about it for a while, perhaps using SecurID would be
the better soluti
Thanks for your explanations, now I understand better how it works. I
updated my fix to store the to_python() values in the instances
__dict__ and it works perfectly.
I don't see other ways to improve that patch, do I have to wait for a
review or can I set the ticket ready for checkin myself ?
L
On Monday 26 November 2007 12:17:51 Ned Batchelder wrote:
> In any case, if the signedcookies code makes you feel better about
> the security of your site, you should certainly use it. There's no
> point in being "disgusted" at Django as a whole.
Agreed - to put it mildly! Django uses a 128 bit
As stated on the code page[1], it uses the New BSD License, though I
really should include that in the source itself.
-Gul
[1] http://code.google.com/p/django-signedcookies/
On Nov 26, 2007 1:57 PM, David Ross @ Wolfeon <[EMAIL PROTECTED]> wrote:
>
> What is the license for the signed cookie co
What is the license for the signed cookie code?
On Nov 26, 4:48 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> On Nov 26, 2007 8:30 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
>
> > I'm not sure what makes you believe that two cookies are more secure
> > than one. Two n-bit strings are just a
On Nov 26, 2007 11:40 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> I regret not having a recent trunk to test this with, but I think
> you'd be better off storing th evalue in the object's namespace
> dictionary instead. I've recently outlined[1] how this works, and you
> can also see a great e
I regret not having a recent trunk to test this with, but I think
you'd be better off storing th evalue in the object's namespace
dictionary instead. I've recently outlined[1] how this works, and you
can also see a great example of it in GeoDjango[2], also linked from
that article.
Essentially, r
I realized my patch may introduce a memory leak : as I understand what's
going on in django.db.models.fields.subclassing, Creator().value becomes
a class attribute for custom field classes that have SubfieldBase as
their __metaclass__, which leads to the problem illustrated in my unit test.
Stori
On Nov 26, 2007 8:30 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
> I'm not sure what makes you believe that two cookies are more secure
> than one. Two n-bit strings are just as secure as one 2n-bit so a
> simple answer would be: make the session ID twice as long.
And that's exactly what the s
On Nov 26, 2007 7:47 AM, David Ross @ Wolfeon <[EMAIL PROTECTED]> wrote:
> I try not to use by IP due to the problem you specified.
Glad to hear it.
> The way I think of the second cookie, is more like a 2nd password.
> Sure, there is a possibility of a brute force with it to, but it is
> less l
2007/11/26, David Ross @ Wolfeon <[EMAIL PROTECTED]>:
>
> I can be unclear at times, especially while I'm very tired. I'll have
> to make an example of what I'm talking about included with an example
> or so. People tend to be a bit more understanding if there is
> something there to play with ins
On Nov 23, 9:28 pm, Collin Grady <[EMAIL PROTECTED]> wrote:
> > I have come up with this kludge:
> > http://www.djangosnippets.org/snippets/479/
> > Should I turn this into a patch and submit it?
>
> No, this will be covered by 4102.
>
> > What's the status of ticket 4102?
> > (Allow UPDATE of onl
I can be unclear at times, especially while I'm very tired. I'll have
to make an example of what I'm talking about included with an example
or so. People tend to be a bit more understanding if there is
something there to play with instead of an idea.
I try not to use by IP due to the problem you
On 11/26/07, James Bennett <[EMAIL PROTECTED]> wrote:
> [1] Actually, a "secure" web application is possible. It just starts
> with not ever connecting the application to the Web. Ideally, the
> server on which the application code and database is kept will also be
> stored inside a nuclear-harden
On 11/26/07, David Ross @ Wolfeon <[EMAIL PROTECTED]> wrote:
> environment, and am rather disgusted at the current state because the
> ticket was opened 11 months ago.
>
> http://code.djangoproject.com/ticket/3285
>
> My recommendation is to incorporate code in the default session module
> which i
A couple of points:
1) the hotmail_hack story you point to is about cross-site scripting,
which has nothing to do with the security of cookies.
2) the signedcookies code you point to for inclusion in Django
explicitly discusses the idea that sessions are not vulnerable and
therefore their cook
I would like to allow the following too:
{% blocktrans %}
Received on {{ message.created|date as date }}
...
this removes the "with-as" stuff from the blocktrans completely
to increase the readablitiy of the entire block and not squeeze all
the variables in at the opening blocktrans
wolfram
also +1
On 26 Nov., 09:55, "Wolfram Kriesing" <[EMAIL PROTECTED]>
wrote:
> +1
>
> Wolfram
>
> On Nov 26, 2007 9:22 AM, alain D. <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Hi,
>
> > Trying to sum up the discussions so far I would say that Wolfram's
> > syntax seems to be the preferred one : i.e. l
+1
Wolfram
On Nov 26, 2007 9:22 AM, alain D. <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Trying to sum up the discussions so far I would say that Wolfram's
> syntax seems to be the preferred one : i.e. letting the logic go into
> the translated string but keeping the strings to translate in one bit
Hi,
Trying to sum up the discussions so far I would say that Wolfram's
syntax seems to be the preferred one : i.e. letting the logic go into
the translated string but keeping the strings to translate in one bit.
I wasn't that in favor of this solution at first but I confess I'm
much more convin
20 matches
Mail list logo
