On 22 Sep 2016, at 20:32, James Bennett wrote:
> So personally I'd like to hear some more about why this is seen as necessary
> before I'd endorse work to actually implement it.
The reason why I originally filed a security report is that session stores tend
to have
For what it's worth, I'm suspicious of threat models which begin with
"assume the DB has already been significantly compromised..." simply
because there's so much someone can do if they gain even read access that
it's not worth expending a ton of effort hardening Django against those
cases.
We have an implementation of both annotations in *list_display* and adding
an aggregates for the entire list (which we call *list_summary* and what
you are calling here *list_aggregates*) and there are a bunch of subtleties
in the interaction due to Admin's built in support for pagination and
On Thursday, 22 September 2016 15:59:12 UTC+1, Sjoerd Job Postmus wrote:
>
> Another part I see is that the high coupling between Django and the URL
> resolvers (as mentioned in
> http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ )
> should probably be cleaned up, if it is
I'll try and update my library over the next couple of days to also support
regex fragments and converters supporting parameters.
Another part I see is that the high coupling between Django and the URL
resolvers (as mentioned in
http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/
Sure, go ahead.
On Thursday, September 22, 2016 at 9:31:35 AM UTC-4, Violet Gibson wrote:
>
> Thanks for ticket link.
>
> Would you mind if I assigned it to myself? I have a few ideas on how
> it could be put together, and I'd like to work on it tonight and
> submit a proposal.
>
> Rigel.
>
Thanks for ticket link.
Would you mind if I assigned it to myself? I have a few ideas on how
it could be put together, and I'd like to work on it tonight and
submit a proposal.
Rigel.
On Thu, Sep 22, 2016 at 2:23 PM, Tim Graham wrote:
> The idea of adding an option to
The idea of adding an option to store the session ID hash rather than the
ID itself was discussed a few years ago on the core team mailing list (see
the "Authentication best practices" thread and "Don't store session IDs in
the clear" in the security issue tracker). Maybe we can reproduce some
> Den 22. sep. 2016 kl. 13.38 skrev Alex Gaynor :
>
> If Django were a different framework, I'd probably think this was a
> reasonable idea. However, Django's ORM is _incredibly_ good at deterring SQL
> injection. In many many years of using and reviewing Django
Wanted to add my support for this.
Personally I'd be totally in favour of considering something along these
lines for core, once there's a fully proven design.
The capture syntax is:
* Far simpler.
* Meets pretty much every single real-world case I ever see.
* Gives us type coercion.
* Also
On Thu, Sep 22, 2016 at 12:31 PM, Curtis Maloney wrote:
> They're just a random string, I don't see how turning them into another
> random string will help? Or do you mean to set the original string in the
> cookie only, and hash them for the key, and hash them _every_
I have noticed that session id's are included in Django debug emails, with
no clear way to filter them out. I'm unsure of the behaviour with 1.9+, but
this is what I've experienced with 1.8.
The way around that issue though is to sign the cookie, so that people
can't just drop the session-id in.
If Django were a different framework, I'd probably think this was a
reasonable idea. However, Django's ORM is _incredibly_ good at deterring
SQL injection. In many many years of using and reviewing Django
applications, SQL injection is vanishingly rare in my experience; therefore
I think this adds
On Thursday, September 22, 2016 at 1:26:19 PM UTC+2, Violet Gibson wrote:
>
> Unless I'm missing something, these ids could be
> vulnerable to SQL injection attacks, if any are discovered or if
> developers misuse features like extra().
Same is true for literally any field a user can write
On 22/09/16 18:52, Rigel wrote:
Hello!
The Django session framework stores session-ids in the database as
plain-text. Unless I'm missing something, these ids could be
vulnerable to SQL injection attacks, if any are discovered or if
developers misuse features like extra().
Firstly, extra()
Hello!
The Django session framework stores session-ids in the database as
plain-text. Unless I'm missing something, these ids could be
vulnerable to SQL injection attacks, if any are discovered or if
developers misuse features like extra(). This vulnerability could be
mitigated if the session-ids
16 matches
Mail list logo