Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

Hi

I have submitted my proposal on GSoC's website. You can find it 
at https://summerofcode.withgoogle.com/serve/5167032660131840/. It would 
get locked (from any further editing) at 25 March 19:00 UTC (which is 
almost 11 hours from now).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/91b0a809-3a51-4165-8bd4-80720f5181bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting lazy middleware initialization

[Aymeric Augustin]

On 24 Mar 2016, at 17:39, David Evans  wrote:
> 
> Currently, middleware is initialized lazily on serving the first request, 
> rather than on application start. There may well have been good reasons for 
> this historically, but I don't think they apply any longer.

Indeed, since 1.7 and the app-loading refactor, Django does its best to crash 
when it starts rather than when it serves the first request. +1 to making this 
change.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/07C77240-8EB5-4800-87E0-9D0E4EA181C2%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting lazy middleware initialization

[Florian Apolloner]

+1 -- Patches welcome :D

On Friday, March 25, 2016 at 11:02:26 AM UTC+1, Aymeric Augustin wrote:
>
> On 24 Mar 2016, at 17:39, David Evans > 
> wrote:
>
>
> Currently, middleware is initialized lazily on serving the first request, 
> rather than on application start. There may well have been good reasons for 
> this historically, but I don't think they apply any longer.
>
>
> Indeed, since 1.7 and the app-loading refactor, Django does its best to 
> crash when it starts rather than when it serves the first request. +1 to 
> making this change.
>
> -- 
> Aymeric.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3d63f9d8-8781-4b9e-8498-9cc7c091831b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting lazy middleware initialization

[David Evans]

Great!

Well the two line patch I suggested to `get_wsgi_application` solves the
problem. But it still leaves the lazy loading mechanism in the code base.
Getting rid of it would obviously be preferable, but is more complex. I'll
work on producing a patch for that though.

Dave
On 25 Mar 2016 10:08 a.m., "Florian Apolloner" 
wrote:

> +1 -- Patches welcome :D
>
> On Friday, March 25, 2016 at 11:02:26 AM UTC+1, Aymeric Augustin wrote:
>>
>> On 24 Mar 2016, at 17:39, David Evans  wrote:
>>
>>
>> Currently, middleware is initialized lazily on serving the first request,
>> rather than on application start. There may well have been good reasons for
>> this historically, but I don't think they apply any longer.
>>
>>
>> Indeed, since 1.7 and the app-loading refactor, Django does its best to
>> crash when it starts rather than when it serves the first request. +1 to
>> making this change.
>>
>> --
>> Aymeric.
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/iIm7M6aUJmU/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3d63f9d8-8781-4b9e-8498-9cc7c091831b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHbVmPyedP2p6YmMyJuChks8JPZyG2eyVx3cr8Vaavyfm64nFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: relative path in {% extends "...base.html" %} like relative import

[Vitaly Bogomolov]

>
>
> Assuming the feature is accepted, at least a ticket and documentation are 
> needed to finish the patch. See the patch review checklist:
>
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
>

Documentation:https://github.com/django/django/pull/6330/commits/0d49bf63aa8855bb8b61d198d8f08d1547de9dcb

My english not good, so i need help with proof reading and advice

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ca9ef569-88ac-4532-a059-a96cf6bff3d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2016] Please Critique (Condition API - Related to Auth)

[Connor Boyle]

This is excellent! Thank you for your comments, they are very helpful and 
thorough–far from amateur. I'll address some of them in no particular 
order, starting with:

>The 'access' conditions must be passed or else any action will be rejected 
and no acknowledgement will be made that it had to do with authorization, 
so as to not unnecessarily leak information (e.g. in the case of the given 
model, if IsInLibrary doesn't pass, any protected view will simply return a 
404 - page not found, instead of 403 - permission denied). I just added an 
explicit definition to my proposal. I guess I had expected the reader to 
infer that from my (much earlier in the proposal) definition of 
'access_conditions'. Not very Pythonic of me!

>Although I see the clear appeal of overriding '|' and '&'–it's both 
intuitive and aesthetically pleasing–I'm against it. Unlike doing this with 
Q objects, where the result (iirc) is another Q object, the result of the 
operators would be an instance of either EveryCondition or AnyCondition. 
I'd rather not implicitly thrust an object of a potentially different class 
on the developer. Furthermore, I'd rather not make the definition of 
BaseCondition refer to EveryCondition and AnyCondition, its sub-classes, if 
I can help it.

>As for Conditions as Q objects (mentioned in form fields filtering), 
Conditions are simply meant to be more generalized than this. For example, 
they might have to evaluate based on the result of the method on a model 
instance, which couldn't be translated to a Q object.

On the other hand, there is a pretty good chance that there would be a 
sub-class for Conditions based on Q objects. However, in order to get the 
view to use them efficiently would require even more special method 
overriding. I'm not sure if I'd be able to justify adding that much 
complexity to the mixin for a special case that would not even be 
particularly hard for the developer to implement given the callback my 
preferred implementation of the mixin would provide. Furthermore, this 
solution doesn't quite feel *correct*, since it would be using something 
other than a Condition's run() and acting as if it were using its logic.

On Friday, March 25, 2016 at 4:21:09 AM UTC+8, is_null wrote:
>
> Hi Connor, 
>
> Overall I find it pretty cool that work on this has been started. 
> There are a few questions I'd like to ask on this proposal. 
>
> In this example: 
>
> class ReadingDelete(UserPassesTestMixin, DeleteView): 
> model = Reading 
>
> def test_func(self): 
> user = self.request.user 
> reading = self.get_object() 
> return reading in user.leader.club.readings.all() 
>
> Should we really fetch the object from all objects and then check it 
> against a "secure" queryset ? After all, there's absolutely no 
> security here between the "get_object()" call and the "reading in ..." 
> test. Wouldn't it be more efficient and safer to try to fetch the 
> object directly from a secure queryset ? ie: self.queryset = 
> user.leader.club.readings.all(); reading = self.get_object(). This 
> somehow relates to the Form Choices Filter sections of the proposal: 
>
> > running a Condition against every instance in a queryset can quickly 
> become very inefficient. For cases when it would be necessary, the mixin 
> would provide a callback to allow the developer to use whatever means they 
> want to more efficiently narrow down the queryset before the Conditions are 
> run against its instances. This may seem like redundant code, however the 
> purposes of the two different "narrowing" methods are not the same, one is 
> for efficiency, one is for security. Rough implementation: 
>
> The implementation is pretty rough indeed: it seems like the queryset 
> is narrowed only if method == 'GET'. Doesn't that mean that a 
> malicious user can validate a form with selected choice that was not 
> displayed in the initial rendering ? 
>
> IMHO this is the most challenging part of the subject this proposal is 
> about. Perhaps if Conditions could translate to combinations of Q 
> objects it would be easier to get the best of both worlds. 
>
>
> > As is probably fairly clear from the above code, a user attempting to 
> access the above view would have to have theiris_staff attribute set to 
> True, otherwise the view will (if the following behavior is not overridden) 
> raise a PermissionDeniederror with an appropriate message provided 
> automatically by conditions.RequestUserCondition. 
>
> What kind of messages would be appropriate to use here ? Wouldn't it 
> be tricky to find safe messages, that wouldn't help a malicious user 
> gain information about the security they are trying to circumvent ? 
> For me, this raises the same problem as with login forms: if an 
> attacker gets a "incorrect username or passord" message on a failed 
> login test then they don't learn if the username exist, whereas having 
> an "incorrect password" message 

Re: [GSoC 2016] Please Critique (Condition API - Related to Auth)

[Connor Boyle]

> On your last point: This may be a very bad idea from the beginning, but 
I'd hope to experiment with making a wrapper object for form.cleaned_data 
whose (the wrapper object's) .__getattribute__() returns the value for that 
key in form.cleaned_data.

For example:
calling wrapper.name would get the value stored in form.cleaned_data['name']

On Friday, March 25, 2016 at 4:21:09 AM UTC+8, is_null wrote:
>
> Hi Connor, 
>
> Overall I find it pretty cool that work on this has been started. 
> There are a few questions I'd like to ask on this proposal. 
>
> In this example: 
>
> class ReadingDelete(UserPassesTestMixin, DeleteView): 
> model = Reading 
>
> def test_func(self): 
> user = self.request.user 
> reading = self.get_object() 
> return reading in user.leader.club.readings.all() 
>
> Should we really fetch the object from all objects and then check it 
> against a "secure" queryset ? After all, there's absolutely no 
> security here between the "get_object()" call and the "reading in ..." 
> test. Wouldn't it be more efficient and safer to try to fetch the 
> object directly from a secure queryset ? ie: self.queryset = 
> user.leader.club.readings.all(); reading = self.get_object(). This 
> somehow relates to the Form Choices Filter sections of the proposal: 
>
> > running a Condition against every instance in a queryset can quickly 
> become very inefficient. For cases when it would be necessary, the mixin 
> would provide a callback to allow the developer to use whatever means they 
> want to more efficiently narrow down the queryset before the Conditions are 
> run against its instances. This may seem like redundant code, however the 
> purposes of the two different "narrowing" methods are not the same, one is 
> for efficiency, one is for security. Rough implementation: 
>
> The implementation is pretty rough indeed: it seems like the queryset 
> is narrowed only if method == 'GET'. Doesn't that mean that a 
> malicious user can validate a form with selected choice that was not 
> displayed in the initial rendering ? 
>
> IMHO this is the most challenging part of the subject this proposal is 
> about. Perhaps if Conditions could translate to combinations of Q 
> objects it would be easier to get the best of both worlds. 
>
>
> > As is probably fairly clear from the above code, a user attempting to 
> access the above view would have to have theiris_staff attribute set to 
> True, otherwise the view will (if the following behavior is not overridden) 
> raise a PermissionDeniederror with an appropriate message provided 
> automatically by conditions.RequestUserCondition. 
>
> What kind of messages would be appropriate to use here ? Wouldn't it 
> be tricky to find safe messages, that wouldn't help a malicious user 
> gain information about the security they are trying to circumvent ? 
> For me, this raises the same problem as with login forms: if an 
> attacker gets a "incorrect username or passord" message on a failed 
> login test then they don't learn if the username exist, whereas having 
> an "incorrect password" message on a failed login test does leak the 
> information that the username exists. That said, this kind of feature 
> would *definitely* by useful for logs. 
>
>
> > Since Clubs no longer have .leader (they now have .leaders), the if 
> statement's condition becomes nonsense, and due to Django templates' policy 
> of silent failure simply doesn't show the contents of the if statement, 
> thus not showing the links to the update and delete pages for that Reading. 
>
> If such a bug is found, then a the DoD of the bugfix should include a 
> regression test to ensure that leaders always see the edit/delete 
> links in the template response. Should Ahmad have duplicate logic in 
> templates like this in the first place ? I recon it's the same problem 
> everybody has to solve in their projects though: perhaps it would be 
> interresting to encapsulate this particular logic in a template filter 
> ? 
>
> {% if reading.club.leader.user == request.user %} 
> Update 
> Delete 
> {% endif %} 
>
> Becomes: 
>
> {% if reading|can_edit:request.user %} 
> Update 
> Delete 
> {% endif %} 
>
> Or, with a context variable, like in the case of django.contrib.admin: 
> {% if has_change_permission %}. That said, I'm all for providing a 
> framework for Ahmad to have a convenient, consistent, secure and 
> forward-compatible way to encapsulate these permission checks. 
>
>
> > Combiners 
> > There would also of course be classes for combining multiple conditions 
> into one. The two "combiners" would beEveryCondition and AnyCondition. 
>
> Would it be nice to leverage & and | operators and perhaps have ~ for 
> negation like with Q objects ? 
>
>
> In this example: 
>
> class Book(models.Model): 
> class Meta: 
> conditions = { 
> 'access': (IsInLibrary,), 
>