Re: Performance optimisations in the deployment checklist document

[Tim Graham]

I don't think there's a reason to recommend one of the two cached sessions 
backends over the other as the choice is application dependent, but +1 on a 
link to 
https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-cached-sessions
 as 
something to consider.

On Thursday, August 15, 2013 12:53:27 PM UTC-4, Marc Tamlyn wrote:
>
> I think we should at consider mentioning the `cached_db` session engine in 
> the performance considerations part of the deployment checklist. It's an 
> easy setting to enable which does give a performance boost, although the 
> hit caused by it is decreased now we have persistent connections. That 
> said, if you're not using `CONN_MAX_AGE`, then there's a huge benefit.
>
> The only issue I can see is that it only improves performance if you've 
> got memcached installed. That's easy to state though, and a reasonably 
> large number of users will be using caching anyway.
>
> Any thoughts?
>
> Marc
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.6 release timeline

[Tim Graham]

Obviously, we've missed our target for the release candidate. We're 
currently targeting the week of August 26 for that, pending no new release 
blockers.

You can help us make our goal by triaging unreviewed 
tickets.
 
Thanks!

On Thursday, May 2, 2013 9:41:46 AM UTC-4, Jacob Kaplan-Moss wrote:
>
> On Thu, May 2, 2013 at 4:42 AM, Aymeric Augustin 
> > wrote: 
> > Shouldn't we push the alpha to May 23rd, all the more since we plan to 
> fork 
> > the stable/1.6.x branch at the beta? 
>
> That sounds reasonable; give us a chance to get any work done at 
> DjangoCon Europe into the tree before we roll the alpha. 
>
> So, revised schedule: 
>
> Alpha: May 23 
> Beta: June 27 
> RC: Aug 8 
> Final: as early as Aug 15, or later if more RCs are needed. 
>
> (Same as the original, just plus an extra week). 
>
> Jacob 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Feature request: read-only admin view

[Trevor Cox]

There are lots of reasons why read-only/view permissions are appropriate 
for an admin system. I'd really like to see this done! I want to be able to 
give readonly admin accounts to my designers, developers, sales reps and 
sales prospects, because I want them to be able to try out the admin 
interface of my live systems.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Feature request: read-only admin view

[Florian Apolloner]

As with most open source projects; if you really want to see this done feel 
free to get coding and submit a patch :)

Cheers,
Florian

On Friday, August 16, 2013 9:01:07 AM UTC+2, Trevor Cox wrote:
>
> There are lots of reasons why read-only/view permissions are appropriate 
> for an admin system. I'd really like to see this done! I want to be able 
> to give readonly admin accounts to my designers, developers, sales reps and 
> sales prospects, because I want them to be able to try out the admin 
> interface of my live systems.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Feature request: read-only admin view

[Trevor Cox]

At least two people have already submitted a patch. The issue is not the 
coding but that the feature request is being rejected. I'm commenting 
because I don't think the arguments against the feature have considered all 
the use cases for read only admin access; they're just assuming that 
providing read only permissions would be for non-administrators such as 
regular website users.

On Friday, 16 August 2013 07:38:54 UTC-7, Florian Apolloner wrote:
>
> As with most open source projects; if you really want to see this done 
> feel free to get coding and submit a patch :)
>
> Cheers,
> Florian
>
> On Friday, August 16, 2013 9:01:07 AM UTC+2, Trevor Cox wrote:
>>
>> There are lots of reasons why read-only/view permissions are appropriate 
>> for an admin system. I'd really like to see this done! I want to be able 
>> to give readonly admin accounts to my designers, developers, sales reps and 
>> sales prospects, because I want them to be able to try out the admin 
>> interface of my live systems.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Feature request: read-only admin view

[Florian Apolloner]

On Friday, August 16, 2013 6:19:03 PM UTC+2, Trevor Cox wrote:
>
> At least two people have already submitted a patch. 
>
Chances that they still work are not really big.
 

> The issue is not the coding but that the feature request is being rejected.
>
I see 3 core-devs in this thread which seem to be in favor of adding it, 
including Russ who wontfixed it previously; so I don't think that rejection 
is an issue here.
 

> I'm commenting because I don't think the arguments against the feature 
> have considered all the use cases for read only admin access; they're just 
> assuming that providing read only permissions would be for 
> non-administrators such as regular website users.
>
Your "I want people to see data in the admin" isn't really a compelling 
argument imo; but either way, as said above already, there are at least 3 
core devs in this thread which are not or no longer opposed to this 
feature. So if you'd like to see this in 1.7 now would be the time to get 
involved.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Performance optimisations in the deployment checklist document

[Daniele Procida]

On Fri, Aug 16, 2013, Tim Graham  wrote:

>I don't think there's a reason to recommend one of the two cached sessions 
>backends over the other as the choice is application dependent, but +1 on a 
>link to 
>https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-cached-
>sessions as 
>something to consider.

There should presumably also be a similar pointer to this topic in the general 
optimisation and performance documentation described in 
.

Daniele

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Changes in Model._meta

[Russell Keith-Magee]

On Thu, Aug 15, 2013 at 6:56 PM, Michal Petrucha wrote:

> Hello,
>
> As part of my GSoC work [1] I did a refactor of ForeignKey whereby I
> turned it into a virtual field which creates an auxiliary concrete
> field to hold the raw value.
>
> As part of this, there are several changes that I did in Model._meta:
>
> 1) There are now more fields in _meta.fields, obviously. For each
>ForeignKey there is now an extra field with `_id` appended to its
>name. This extra field is not editable nor serializable, which
>means things like serialization, ModelForms or the admin just
>ignore it, however, I have no idea what other things people use
>_meta.fields for and it might cause problems for third-party
>projects.
>

I can imagine this causing *massive* problems -- for example, in the admin
(or just on form sets, for that matter), the "list of fields" is used to
dynamically generate a list of elements needed on a form. If every
ForeignKey is now on the list twice, there's going to be a *huge* set of
changes required.


> 2) I ditched _meta.virtual_fields and put all fields into local_fields
>instead. The reason is simple, since ForeignKey is now virtual, in
>a lot of places where local_fields is accessed, I'd have to search
>local_fields + virtual_fields. Basically, the only reason for
>virtual_fields that I could find was that they were cloned in each
>model subclass, more on this in the next item.
>

Well, the reason is that the virtual fields aren't *exactly* like normal
fields -- they don't literally exist on the database, for example. So, if
we're merging virtual_fields with local_fields, there needs to be a way to
tell the two apart.


> 3) No more cloning of all virtual fields in each model subclass.
>Currently, each field in virtual_fields in parent models is cloned
>in ModelBase.__new__ and added to the subclass as a separately
>owned field. This is rather redundant for most virtual field types
>(in master that would only be GenericForeignKey and
>GenericRelation, in my composite-fields branch there's also
>ForeignKey and CompositeField). The only "field" which requires
>cloning is GenericRelation which needs to determine when it's
>accessed through a model subclass to retrieve the right content
>type.
>
>For other field types this is not necessary and in the case of
>ForeignKey it might even cause undesired effects, like multiple
>conflicting reverse ForeignKey pointers to a target model. Also,
>all related object descriptors and possibly other objects would be
>recreated separately for each subclass. While those should be
>possible to deal with, I'm still not a big fan of creating clones
>of objects and adding extra complexity to account for this without
>any real reason.
>
>Therefore, instead of cloning all virtual fields, each field class
>now has an attribute `clone_in_subclasses` which is True in
>GenericRelation and False everywhere else. Those fields with this
>attribute set to True will end up in private_fields instead of
>local_fields.
>
> To see the whole diff, check out the pull request I created [2].
>
> I'd like people's opinions on these changes. What's the status of
> Model._meta? Last time I saw, it was in the state of a semi-private
> API -- it is not really public as it is not documented anywhere, but a
> LOT of people still use it in their projects because it's considered
> quite stable.
>
> As I said, I don't really know what people use _meta for in their
> projects and it's rather difficult for me to anticipate in what ways
> these changes can break things for them.
>
> Anssi suggested in a comment [3] to keep fields as close to the
> current state as possible, which means ForeignKey would appear there
> and the auxiliary fields it creates would not and create something
> like all_fields which would hold those as well. It is certainly
> possible to do this, but personally, I'm not really convinced -- it
> would mean I'd have to rewrite practically all occurrences od
> _meta.fields in Django to _meta.all_fields and it would introduce
> certain ambiguity as it would not really be clear what the difference
> between fields and all_fields is.
>
> So, I'd like your opinions. The more the better. Whatever the outcome,
> all changes will be thoroughly documented in the release notes which
> I'll start working on as soon as a conclusion is reached.
>

Ok - so my opinion is that _meta needs to be treated as "unofficially
stable" API. If you're proposing changes to _meta, we need to be *very*
careful about those changes, because there are lots of people that are
relying on the current internal structure of _meta. And while it isn't
*officially* stable API, we won't win any friends if we start massively
tinkering with it.

There's definitely a *lot* of improvements that can be made to the
internals of _meta. It's a bit of a mess, with all sorts of things being
cache

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Russell Keith-Magee]

On Fri, Aug 16, 2013 at 7:45 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> 8. I've added a new check. If you're using a `GenericRelation` but there
>> is no
>> `GenericForeignKey` on the target model, an warning is raised. This check
>> was
>> implemented in this commit [9]. It uses `vars` builtin function to check
>> if the
>> target model has a `GenericForeignKey`. This is ugly, but I don't see a
>> better
>> approach.
>>
>> [9]
>> https://github.com/chrismedrela/django/commit/ab65ff2b6d6346407a11a72c072e358c7b518cf9#L1R397
>>
>
> Hrm. I don't really like this, but I'm not sure I have a better option. A
> better approach would be to have GFKs turn up in get_fields, but it isn't
> your responsibility to fix the internal problems of Generic Foreign Keys.
> If we have to live with this, then we should at the very least document it
> as a FIXME, pointing at the underlying problem with _meta handling of GFKs.
>
>

Michal Petruca just mailed the django-dev list with some discussion about
changes he wants to make in his own GSoC project, which drew my attention
to something I'd forgotten about.

Does _meta.virtual_fields -- contain the information you need? It looks
like it should.

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: CSRF protection question

[Russell Keith-Magee]

On Thu, Aug 15, 2013 at 7:21 PM, James Roper  wrote:

> Hi,
>
> I'm a core dev on Play Framework, and I'm currently looking closely at our
> CSRF protection and making improvements, and so I'm looking carefully at
> what other frameworks do because when it comes to security, it's easy to
> miss something.
>
> I'd like to get a better understanding of the reason behind why
> X-Requested-With is no longer supported in Django.  I've read about the
> vulnerability behind it:
>
> https://blog.whitehatsec.com/flash-307-redirect-game-over/
>
> What I don't understand is why this vulnerability required server side
> fixes.  It's clearly a client side vulnerability, here's the Firefox
> version of the vulnerability in the NVD:
>
> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0059
>
> It is clearly stated that the vulnerability is in Firefox, not on the
> server side.  Firefox has since fixed the issue.  The issue is also fixed
> in Chrome:
>
> https://code.google.com/p/chromium/issues/detail?id=63698
>
> So what I don't understand is why Django and Rails both raced to fix this
> on the server side?  It makes it a pain in both frameworks to do AJAX
> calls, where X-Request-With was such a simple solution.  And now that
> clients are fixed, the server side fixes don't seem to be necessary
> anymore.  Is there something I've missed?
>
> Yes. Firefox and Chrome have *subsequently* fixed the issue. But you have
no control over user space, and you have absolutely no guarantee that *all*
users are using fixed browsers. Users don't always update browsers when
they're told to, even if you flash a "YOU ARE COMPROMISED! UPDATE!!1!"
banner in front of them. There *were* compromised browsers in the wild, and
we have no reason to believe that *every one of them* has been updated to
remove the problem.

I completely agree that the AJAX hole was very convenient. However, as a
project, Django wasn't willing to allow *any* possibility of an exploit,
now or in the future, so we had to remove the exception.


> Also, was this ever really fixed in Django?  Rails stores the token in the
> session, but Django stores the token in a cookie.  But since the
> vulnerability allowed setting arbitrary headers, couldn't an attacker just
> set the Cookie header to set the token to be whatever they wanted, and
> submit a token in the form that matched?  I ask because Play has an option
> that allows storing the token in a cookie, and I'd like to fully understand
> what if any issues there are with that (I can see from the Django source
> code that mitm attacks with SSL are a big pain to deal with for one).
>

I'll stand corrected on this, but the vulnerability wasn't about
*completely* arbitrary headers -- it was just the extension headers. To the
best of my knowledge, cookies are still safe -- they can't be set across
domains, unless you have either a MITM attack vector, or a
subdomain/wildcard cookie.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.