It seems to me a setting is not the way to go, but a custom storage would
be better. I've made a custom storage the computes the md5 of the content
and uses that as the directory of the file, though that generate a whole
lot of directories. In a lot of ways, I think it would be great if django
Did you look at the github code search link on my previous email? You may
substitute the other CSRF setting names and determine if you think people
are doing legitimate things or not.
On Monday, August 4, 2014 5:13:57 PM UTC-4, Wes Alvaro wrote:
>
> Yeah, I would agree with you. You should know
Stupid phone
The reason for that cipher over xor was to avoid non printable characters.
Any other solution is fine. Xoring the lower 4 bits reduced the entropy too
much in my view.
On Aug 5, 2014 6:11 AM, "Donald Stufft" wrote:
> On August 3, 2014 at 9:48:53 PM, Adam Brenecki (adambrene...@gmai
As mentioned the cipher choice was mine. It was, also as mentioned
On Aug 5, 2014 6:11 AM, "Donald Stufft" wrote:
> On August 3, 2014 at 9:48:53 PM, Adam Brenecki (adambrene...@gmail.com)
> wrote:
> > The patch I've written implements this mitigation, with one difference:
> > instead of using xor
Yeah, I would agree with you. You should know what your csrf middleware is
doing when you enable it so you should know what cookie name, etc is being
used for your JS.
On Aug 4, 2014 12:56 PM, "Donald Stufft" wrote:
>
>
> On August 4, 2014 at 3:52:56 PM, Wes Alvaro (he...@wesalvaro.com) wrote:
>
On August 3, 2014 at 9:48:53 PM, Adam Brenecki (adambrene...@gmail.com) wrote:
> The patch I've written implements this mitigation, with one difference:
> instead of using xor, it uses a Vigenère cipher (as suggested by FunkyBob),
> as xor was creating non-printable characters which caused problems
Hi All,
The current Options implementation has properties for "concrete fields".
Technically speaking, concrete fields are data fields without a column. The
only concrete field in the codebase is ForeignObject. There are 2 classes
that inherit from ForeignObject: GenericRelation and ForeignKey,
On August 4, 2014 at 3:52:56 PM, Wes Alvaro (he...@wesalvaro.com) wrote:
> I don't see that as a drawback at all. Third party code should not be
> concerned with the CSRF cookie information. There's a separation of
> concerns that's being violated there. Are you speaking from knowledge of
> 3rd p
I don't see that as a drawback at all. Third party code should not be
concerned with the CSRF cookie information. There's a separation of
concerns that's being violated there. Are you speaking from knowledge of
3rd party code needing access to this data or hypothetically? If you have
an example
Hi,
I opened a ticket suggesting to add a new setting to determine how
duplicate filename will be named:
https://code.djangoproject.com/ticket/23183
Tim asked me to bring this to the mailinglist to discuss further this
change and eventually decide if this is worth considering or if it's a no
go.
On 4 August 2014 16:14, Daniel Pyrathon wrote:
> Hi All,
>
> This has been resolved by using the ImmutableList datastructure
>
> https://github.com/PirosB3/django/blob/soc2014_meta_refactor_upgrade_flags_get_field_tree/django/db/models/options.py#L629
>
But why? What's the benefit over using a tu
On Monday, August 4, 2014 4:21:43 PM UTC+2, Michael Mior wrote:
>
> This looks good, although it seems like there should be a config setting
> as I could imagine some use cases where the application expects the token
> not to change in this way. I'm not sure how common this and whether or not
>
This looks good, although it seems like there should be a config setting as
I could imagine some use cases where the application expects the token not
to change in this way. I'm not sure how common this and whether or not such
a setting should be enabled by default, but I think it should be cons
Hi All,
This has been resolved by using the ImmutableList datastructure
https://github.com/PirosB3/django/blob/soc2014_meta_refactor_upgrade_flags_get_field_tree/django/db/models/options.py#L629
On Monday, August 4, 2014 2:44:38 PM UTC+2, Collin Anderson wrote:
>
> if we do really need a list, c
if we do really need a list, could we gain some performance by caching
tuples and converting them to lists instead of caching lists?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails f
1) get_fields should return a list instead of a tuple
>>> Previously, get_fields would return a tuple. The main reason was
related to memory and immutability. After discussing with Russell, we
decided this endpoint should actually return a list as it is a more suited
data structure.
>> Can
On Monday, August 4, 2014 11:01:14 AM UTC+2, Adam Brenecki wrote:
>
> What is wrong with xor+base64? Not that Vigenère cipher is complex, but we
>> have a pretty hard stance against implementing "crypto" on our own.
>>
>
> Nothing, really; that's probably what I would have used had FunkyBob not
On 4 August 2014 17:47, Florian Apolloner wrote:
>
> (eg credit card data could still get leaked, so you'd still have to
> disable gzip).
>
This patch is entirely about preventing leakage of the CSRF token
specifically; as I understand it (again, disclaimer) it should do that
pretty effectively,
Hi,
On Monday, August 4, 2014 3:15:15 AM UTC+2, Adam Brenecki wrote:
>
> So, a while ago, BREACH happened, and Django's CSRF implementation was
> vulnerable, as was Rails'. The paper that discussed it described a
> mitigation (and a Rails patch had already been made), so I implemented that
> sa
19 matches
Mail list logo
