Summer of Code Idea: Class-based [Object] Permissions

[Connor Boyle]

As I understand, some parts of Django-Rest-Framework 
<http://www.django-rest-framework.org/> are being considered for 
integration into Django (please correct me if I'm mistaken). I'm not sure 
what specifically core plans to bring in, but in my opinion the feature 
that core Django needs the most from DRF has no direct connection to APIs 
or JSON: it's the extremely well-designed class-based permissions system 
<http://www.django-rest-framework.org/api-guide/permissions/>.

For those who aren't familiar, the bottom line is that it's a system that 
allows the developer to run their own arbitrary code (in a clean, DRY, and 
readable way) to determine whether or not to return a 403 given a 
particular request and view. Any class-based view (with the provided mixin) 
can be assigned a tuple of permissions to check. In other words, it is the 
answer to our prayers.

Example:

MyApp/permissions.py: 
from rest_framework import permissions


class IsFromTexas(permissions.BasePermission):
'''Only allow users from Texas.
'''
def has_permission(self, request, view):
return request.user.state == 'TEXAS'

MyApp/views.py:
from MyApp.permissions import IsFromTexas
# Other imports

class MapOfTexasView(ClassPermissionsMixin, TemplateView):  # 
ClassPermissionsMixin does not actually exist yet
'''Return a map of Texas. Only allow users from Texas.
'''
permission_classes = (IsFromTexas,)
template_name = 'map_of_texas.html'

Checking against an object is trivial, and DRF's implementation makes it 
even easier and cleaner by providing a has_object_permission() method that 
gets passed the result of the view's get_object() if it has one (and makes 
it so the developer doesn't have to worry about accidentally calling 
get_object() multiple times).

I'm considering applying for Summer of Code with this (adding class-based 
permissions to Django) as the subject of my proposal. I would also add some 
features that DRF is missing, such as permission-checking on QuerySets, 
adding class-based permission checking to default class-based views, and 
dividing permissions into read and write.

A few questions for anyone who can answer them:

1. Is there any chance of getting this accepted as a feature? (through 
Summer of Code or otherwise)
2. Is this appropriate in scope and significance for a Summer of Code 
project? I'm guessing it would be relatively little actual code, but could 
potentially be a fundamental part of a huge number of projects made with 
Django.
3. I suspect that if this were to be added to Django core, we'd want to use 
a name other than 'permissions' given that Django already has its own 
permissions system that uses that name. How does 'authorizations' sound?


Connor Boyle
Macalester College

-- 
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/d89393a0-e8f1-4398-9643-de4cc6d958da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

[Connor Boyle]

My original inspiration actually was Django Rest Framework, but I wanted to 
show that I had actually thought it out and that it is indeed possible to 
implement in core Django (albeit not quite as cleanly as DRF does it). I'll 
try to finish a more detailed write-up of how they compare, but in short 
they are very similar. In terms of overall paradigm, the largest difference 
is that DRF's "permissions" are designed exclusively for being run given 
the request or the request and the result of get_object(). My proposal, on 
the other hand, would allow conditions to be written that don't require 
these arguments and in fact require other arguments, although it does 
provide appropriate sub-classes for these extremely common usage cases. 
This is enabled by one other key difference between the two: my proposal's 
separation between the evaluate() layer–the one that's generally overridden 
by the developer or by common usage sub-classes–and the run() layer–which 
calls the evaluate() layer after picking which keyword arguments it should 
pass to it.

On Thursday, March 17, 2016 at 1:31:37 AM UTC+8, Ryan Hiebert wrote:
>
>
> On Mar 16, 2016, at 11:55 AM, Connor Boyle  > wrote:
>
> I'm hoping to add a feature that I've thought Django has needed for a long 
> time, and thought that Google Summer of Code would be an excellent 
> opportunity for it. Basically, it would be an API for defining 'Conditions' 
> and applying them to Views. [snip]
>
> 1. How clear and convincing is the section describing what's wrong with 
> the current solution ('The Problem(s)')? Any criticisms on that section 
> would be very welcome.
>
>
> It seems like a neat idea, and reasonably well thought out, though I don't 
> have the standing needed to speak to its viability as a GSOC project or for 
> inclusion in Django. I'd be interested to see a write-up comparing this 
> with Django Rest Framework's Permissions, which seem pretty similar in 
> concept. http://www.django-rest-framework.org/api-guide/permissions/
>

-- 
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/ec27e07e-478a-43cd-83ef-4aa53efed5eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

[Connor Boyle]

My original inspiration actually was Django Rest Framework, but I wanted to 
show that I had actually thought it out and that it is indeed possible to 
implement (albeit not quite as cleanly as DRF does it). I'll try to finish 
a more detailed write-up of how they compare, but in short they are very 
similar. In terms of overall paradigm, the largest difference is that DRF's 
"permissions" are designed exclusively for being run given the request or 
the request and the result of get_object(). My proposal, on the other hand, 
would allow conditions to be written that don't require these arguments and 
in fact require other arguments, although it does provide appropriate 
sub-classes for these extremely common usage cases.

On Thursday, March 17, 2016 at 12:55:04 AM UTC+8, Connor Boyle wrote:
>
> I'm hoping to add a feature that I've thought Django has needed for a long 
> time, and thought that Google Summer of Code would be an excellent 
> opportunity for it. Basically, it would be an API for defining 'Conditions' 
> and applying them to Views. Common usages would include restricting views 
> based on whether a user is the owner of an object (as determined by a 
> ForeignKey), whether a group-style object has the capacity to add another 
> object to its members, whether the user has a certain permission, etc. 
> Though Django recently added some Auth-related mixins (e.g. 
> UserPassesTestMixin 
> <https://docs.djangoproject.com/en/1.9/topics/auth/default/#django.contrib.auth.mixins.UserPassesTestMixin>)
>  
> that get the job done in simple situations, however the lack of separation 
> between view-related functionality and condition-evaluation code severely 
> limits their usability in more complex situations.
>
> My proposal <https://gist.github.com/cascadianblue/48af15d511ec67e54411> 
> is still not entirely done (no timeline and the implementation section 
> needs a lot of clarification), but it looks like time is getting fairly 
> tight so I figured I should reach out ASAP. I was particularly hoping to 
> get feedback on the part of my proposal where I assert that it is necessary 
> in the first place ('The Problem(s)').
>
> Questions:
> 1. How clear and convincing is the section describing what's wrong with 
> the current solution ('The Problem(s)')? Any criticisms on that section 
> would be very welcome.
> 2. Are you or anyone you know interested in mentoring on this project?
>

-- 
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/a925f325-1089-4eef-82f6-11bcc2ac89f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

[Connor Boyle]

I'm hoping to add a feature that I've thought Django has needed for a long 
time, and thought that Google Summer of Code would be an excellent 
opportunity for it. Basically, it would be an API for defining 'Conditions' 
and applying them to Views. Common usages would include restricting views 
based on whether a user is the owner of an object (as determined by a 
ForeignKey), whether a group-style object has the capacity to add another 
object to its members, whether the user has a certain permission, etc. 
Though Django recently added some Auth-related mixins (e.g. 
UserPassesTestMixin 
)
 
that get the job done in simple situations, however the lack of separation 
between view-related functionality and condition-evaluation code severely 
limits their usability in more complex situations.

My proposal  is 
still not entirely done (no timeline and the implementation section needs a 
lot of clarification), but it looks like time is getting fairly tight so I 
figured I should reach out ASAP. I was particularly hoping to get feedback 
on the part of my proposal where I assert that it is necessary in the first 
place ('The Problem(s)').

Questions:
1. How clear and convincing is the section describing what's wrong with the 
current solution ('The Problem(s)')? Any criticisms on that section would 
be very welcome.
2. Are you or anyone you know interested in mentoring on this project?

-- 
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/ef9f3369-cbb6-4cef-b538-768d4961ef38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

[Connor Boyle]

I'm still working on fleshing out how specifically to add them into 
function-based views–what code the API should provide to automate or 
semi-automate the auth-related functionality once a Condition has failed 
(redirect to login, etc.). I'll get that in my proposal ASAP, but if you 
have any particular suggestions or (more likely) warnings, I'd really 
appreciate it.

On Friday, March 18, 2016 at 11:01:27 PM UTC+8, Connor Boyle wrote:
>
> Yes, definitely! That was something I had in mind coming up with the 
> concept. The "Conditions" themselves are written with no knowledge of and 
> have no relation to class-based views, they simply give a pass or a fail 
> given certain conditions.
>
> On Friday, March 18, 2016 at 10:56:46 PM UTC+8, Collin Anderson wrote:
>>
>> Hi Connor,
>>
>> I personally usually avoid class based views whenever possible and stick 
>> to function based views whenever possible. Would these Conditions be usable 
>> within function based views too?
>>
>> Thanks,
>> Collin
>>
>>
>> On Thursday, March 17, 2016 at 8:00:16 AM UTC-4, Connor Boyle wrote:
>>>
>>> My original inspiration actually was Django Rest Framework, but I wanted 
>>> to show that I had actually thought it out and that it is indeed possible 
>>> to implement in core Django (albeit not quite as cleanly as DRF does it). 
>>> I'll try to finish a more detailed write-up of how they compare, but in 
>>> short they are very similar. In terms of overall paradigm, the largest 
>>> difference is that DRF's "permissions" are designed exclusively for being 
>>> run given the request or the request and the result of get_object(). My 
>>> proposal, on the other hand, would allow conditions to be written that 
>>> don't require these arguments and in fact require other arguments, although 
>>> it does provide appropriate sub-classes for these extremely common usage 
>>> cases. This is enabled by one other key difference between the two: my 
>>> proposal's separation between the evaluate() layer–the one that's generally 
>>> overridden by the developer or by common usage sub-classes–and the run() 
>>> layer–which calls the evaluate() layer after picking which keyword 
>>> arguments it should pass to it.
>>>
>>> On Thursday, March 17, 2016 at 1:31:37 AM UTC+8, Ryan Hiebert wrote:
>>>>
>>>>
>>>> On Mar 16, 2016, at 11:55 AM, Connor Boyle  
>>>> wrote:
>>>>
>>>> I'm hoping to add a feature that I've thought Django has needed for a 
>>>> long time, and thought that Google Summer of Code would be an excellent 
>>>> opportunity for it. Basically, it would be an API for defining 
>>>> 'Conditions' 
>>>> and applying them to Views. [snip]
>>>>
>>>> 1. How clear and convincing is the section describing what's wrong with 
>>>> the current solution ('The Problem(s)')? Any criticisms on that section 
>>>> would be very welcome.
>>>>
>>>>
>>>> It seems like a neat idea, and reasonably well thought out, though I 
>>>> don't have the standing needed to speak to its viability as a GSOC project 
>>>> or for inclusion in Django. I'd be interested to see a write-up comparing 
>>>> this with Django Rest Framework's Permissions, which seem pretty similar 
>>>> in 
>>>> concept. http://www.django-rest-framework.org/api-guide/permissions/
>>>>
>>>

-- 
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/2df0e9da-3629-414f-a781-372acb179433%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

[Connor Boyle]

Yes, definitely! That was something I had in mind coming up with the 
concept. The "Conditions" themselves are written with no knowledge of and 
have no relation to class-based views, they simply give a pass or a fail 
given certain conditions.

On Friday, March 18, 2016 at 10:56:46 PM UTC+8, Collin Anderson wrote:
>
> Hi Connor,
>
> I personally usually avoid class based views whenever possible and stick 
> to function based views whenever possible. Would these Conditions be usable 
> within function based views too?
>
> Thanks,
> Collin
>
>
> On Thursday, March 17, 2016 at 8:00:16 AM UTC-4, Connor Boyle wrote:
>>
>> My original inspiration actually was Django Rest Framework, but I wanted 
>> to show that I had actually thought it out and that it is indeed possible 
>> to implement in core Django (albeit not quite as cleanly as DRF does it). 
>> I'll try to finish a more detailed write-up of how they compare, but in 
>> short they are very similar. In terms of overall paradigm, the largest 
>> difference is that DRF's "permissions" are designed exclusively for being 
>> run given the request or the request and the result of get_object(). My 
>> proposal, on the other hand, would allow conditions to be written that 
>> don't require these arguments and in fact require other arguments, although 
>> it does provide appropriate sub-classes for these extremely common usage 
>> cases. This is enabled by one other key difference between the two: my 
>> proposal's separation between the evaluate() layer–the one that's generally 
>> overridden by the developer or by common usage sub-classes–and the run() 
>> layer–which calls the evaluate() layer after picking which keyword 
>> arguments it should pass to it.
>>
>> On Thursday, March 17, 2016 at 1:31:37 AM UTC+8, Ryan Hiebert wrote:
>>>
>>>
>>> On Mar 16, 2016, at 11:55 AM, Connor Boyle  
>>> wrote:
>>>
>>> I'm hoping to add a feature that I've thought Django has needed for a 
>>> long time, and thought that Google Summer of Code would be an excellent 
>>> opportunity for it. Basically, it would be an API for defining 'Conditions' 
>>> and applying them to Views. [snip]
>>>
>>> 1. How clear and convincing is the section describing what's wrong with 
>>> the current solution ('The Problem(s)')? Any criticisms on that section 
>>> would be very welcome.
>>>
>>>
>>> It seems like a neat idea, and reasonably well thought out, though I 
>>> don't have the standing needed to speak to its viability as a GSOC project 
>>> or for inclusion in Django. I'd be interested to see a write-up comparing 
>>> this with Django Rest Framework's Permissions, which seem pretty similar in 
>>> concept. http://www.django-rest-framework.org/api-guide/permissions/
>>>
>>

-- 
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/f56e5ac5-4159-4d09-939f-7e7e2adfb69e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

[Connor Boyle]

Hello everyone,

I've updated my proposal 
<https://gist.github.com/cascadianblue/2856bea128dd1b3f4d0f> fairly 
dramatically (different link than before). I've written a lot of code to 
show just how much of a mess the problem I'm trying to solve is, but 
unfortunately haven't quite had time to finish it (and therefore haven't 
added it at all), so the Example section is rather thin and might not be as 
convincing as it will be when I've add those in. It's also missing a couple 
of sections on potential hooks that I haven't quite finished writing.

What I'm really hoping to get feedback on is the "Implementation" 
section–particularly the "Core", so please everyone critique at will.

On Friday, March 18, 2016 at 11:08:57 PM UTC+8, Connor Boyle wrote:
>
> I'm still working on fleshing out how specifically to add them into 
> function-based views–what code the API should provide to automate or 
> semi-automate the auth-related functionality once a Condition has failed 
> (redirect to login, etc.). I'll get that in my proposal ASAP, but if you 
> have any particular suggestions or (more likely) warnings, I'd really 
> appreciate it.
>
> On Friday, March 18, 2016 at 11:01:27 PM UTC+8, Connor Boyle wrote:
>>
>> Yes, definitely! That was something I had in mind coming up with the 
>> concept. The "Conditions" themselves are written with no knowledge of and 
>> have no relation to class-based views, they simply give a pass or a fail 
>> given certain conditions.
>>
>> On Friday, March 18, 2016 at 10:56:46 PM UTC+8, Collin Anderson wrote:
>>>
>>> Hi Connor,
>>>
>>> I personally usually avoid class based views whenever possible and stick 
>>> to function based views whenever possible. Would these Conditions be usable 
>>> within function based views too?
>>>
>>> Thanks,
>>> Collin
>>>
>>>
>>> On Thursday, March 17, 2016 at 8:00:16 AM UTC-4, Connor Boyle wrote:
>>>>
>>>> My original inspiration actually was Django Rest Framework, but I 
>>>> wanted to show that I had actually thought it out and that it is indeed 
>>>> possible to implement in core Django (albeit not quite as cleanly as DRF 
>>>> does it). I'll try to finish a more detailed write-up of how they compare, 
>>>> but in short they are very similar. In terms of overall paradigm, the 
>>>> largest difference is that DRF's "permissions" are designed exclusively 
>>>> for 
>>>> being run given the request or the request and the result of get_object(). 
>>>> My proposal, on the other hand, would allow conditions to be written that 
>>>> don't require these arguments and in fact require other arguments, 
>>>> although 
>>>> it does provide appropriate sub-classes for these extremely common usage 
>>>> cases. This is enabled by one other key difference between the two: my 
>>>> proposal's separation between the evaluate() layer–the one that's 
>>>> generally 
>>>> overridden by the developer or by common usage sub-classes–and the run() 
>>>> layer–which calls the evaluate() layer after picking which keyword 
>>>> arguments it should pass to it.
>>>>
>>>> On Thursday, March 17, 2016 at 1:31:37 AM UTC+8, Ryan Hiebert wrote:
>>>>>
>>>>>
>>>>> On Mar 16, 2016, at 11:55 AM, Connor Boyle  
>>>>> wrote:
>>>>>
>>>>> I'm hoping to add a feature that I've thought Django has needed for a 
>>>>> long time, and thought that Google Summer of Code would be an excellent 
>>>>> opportunity for it. Basically, it would be an API for defining 
>>>>> 'Conditions' 
>>>>> and applying them to Views. [snip]
>>>>>
>>>>> 1. How clear and convincing is the section describing what's wrong 
>>>>> with the current solution ('The Problem(s)')? Any criticisms on that 
>>>>> section would be very welcome.
>>>>>
>>>>>
>>>>> It seems like a neat idea, and reasonably well thought out, though I 
>>>>> don't have the standing needed to speak to its viability as a GSOC 
>>>>> project 
>>>>> or for inclusion in Django. I'd be interested to see a write-up comparing 
>>>>> this with Django Rest Framework's Permissions, which seem pretty similar 
>>>>> in 
>>>>> concept. http://www.django-rest-framework.org/api-guide/permissions/
>>>>>
>>>>

-- 
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/029964ca-b83d-4f29-8bcb-f33ce6d5c654%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Connor Boyle]

Hello Everyone,

I would love to hear your critiques on my proposal 
 and original 
idea for GSoC 2016, hopefully before the deadline tomorrow–although I plan 
on pursuing it no matter what, so any critique at any time would be welcome 
(including those questioning the merit/need of the concept).

In case you haven't seen any of my other posts, it is closely based on 
Django Rest Framework's 'permissions', however it extends significantly 
beyond them in terms of what a developer can use them to accomplish.

I am on Beijing time (UTC +8) so I will be asleep and then in class for the 
next twelve hours, so sorry if I don't respond until after that.

Thanks,
Connor

-- 
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/1a4e09f9-25c4-42a0-9111-19f50a16dfe7%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,), 
>   

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

[Connor Boyle]

Hello all,
Is there any chance I could get some feedback on why this was not accepted? 
I am a little surprised since Jacob Kaplan-Moss seemed to indicate to me 
over IRC that this was very likely to get an award for GSoC.
Thanks,
Connor

On Saturday, March 26, 2016 at 12:47:52 AM UTC+8, Connor Boyle wrote:
>
> > 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 
>> 

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

[Connor Boyle]

Thanks for the response, Tim.

On Saturday, April 23, 2016 at 8:04:02 AM UTC+8, Tim Graham wrote:
>
> Hi Connor,
>
> Unfortunately we didn't have anyone sufficiently intrigued by your ideas 
> who wanted to mentor it. In case you'd like to try again next year, I'd 
> suggest to get involved in the project and start submitting patches as 
> you're able. Mentors are more wiling to invest their time to help someone 
> who has a record of solid contributions.
>
> Tim
>
> On Friday, April 22, 2016 at 7:46:19 PM UTC-4, Connor Boyle wrote:
>>
>> Hello all,
>> Is there any chance I could get some feedback on why this was not 
>> accepted? I am a little surprised since Jacob Kaplan-Moss seemed to 
>> indicate to me over IRC that this was very likely to get an award for GSoC.
>> Thanks,
>> Connor
>>
>> On Saturday, March 26, 2016 at 12:47:52 AM UTC+8, Connor Boyle wrote:
>>>
>>> > 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 a

Conditions DEP

[Connor Boyle]

I'd like to make a proposal for the addition of a major new feature to 
Django. Back in late March of this year, I wrote an original Google Summer 
of Code proposal 
 that received 
some interest from several members of the community, but neither I nor this 
proposal were selected for GSoC. A community member (iirc it was Florian 
Apolloner) told me to put the proposal in the form of a DEP.

For those not previously introduced (or who need a reminder), this proposal 
is for a standardized system of "conditions"–dynamic rules written in plain 
Python–which would be used primarily to evaluate whether an action (in most 
cases, the execution of a view) should be allowed. Comparable features 
include Django-Rules and the permissions system in Django Rest Framework.

The current version of the DEP is attached here 
.
 
I am currently seeking at least a shepherd and hopefully other 
implementors. Any and all thoughtful critique would be highly appreciated.

Thanks,
Connor

-- 
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/1121041a-d506-4052-9307-48609b1f4cfd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Conditions DEP

[Connor Boyle]

Thanks Tim,

A pull request would be great, though I think it would be best for 
posterity to post a link to it on this thread.

Posting directly on this thread (with quotes of relevant sections of the 
proposal) I think would also work fine.

On Monday, June 6, 2016 at 6:29:48 AM UTC-7, Tim Allen wrote:
>
> Hi Connor,
>
> How would you prefer suggested tweaks to your proposal? Since it is on 
> GitHub, would you prefer pull requests? Thank you for taking the initiative!
>
> Regards,
>
> Tim
>
> On Sunday, June 5, 2016 at 10:52:57 PM UTC-4, Connor Boyle wrote:
>>
>> I'd like to make a proposal for the addition of a major new feature to 
>> Django. Back in late March of this year, I wrote an original Google 
>> Summer of Code proposal 
>> <https://gist.github.com/cascadianblue/2856bea128dd1b3f4d0f> that 
>> received some interest from several members of the community, but neither I 
>> nor this proposal were selected for GSoC. A community member (iirc it was 
>> Florian Apolloner) told me to put the proposal in the form of a DEP.
>>
>> For those not previously introduced (or who need a reminder), this 
>> proposal is for a standardized system of "conditions"–dynamic rules written 
>> in plain Python–which would be used primarily to evaluate whether an action 
>> (in most cases, the execution of a view) should be allowed. Comparable 
>> features include Django-Rules and the permissions system in Django Rest 
>> Framework.
>>
>> The current version of the DEP is attached here 
>> <https://github.com/cascadianblue/DEP-Conditions-API/blob/master/-conditions-api.rst>.
>>  
>> I am currently seeking at least a shepherd and hopefully other 
>> implementors. Any and all thoughtful critique would be highly appreciated.
>>
>> Thanks,
>> Connor
>>
>

-- 
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/d8bc600d-ade6-41c3-b105-c50060476383%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Conditions DEP

[Connor Boyle]

Hi Carl,

Should I stop working on the DEP then? Also, would it be at all appropriate 
to continue using this mailing list (for say, updates on the project and 
requests for review)?

Thanks,
Connor

On Monday, June 6, 2016 at 9:34:45 AM UTC-7, Carl Meyer wrote:
>
> Hi Connor, 
>
> On 06/05/2016 07:52 PM, Connor Boyle wrote: 
> > I'd like to make a proposal for the addition of a major new feature to 
> > Django. Back in late March of this year, I wrote an original Google 
> > Summer of Code proposal 
> > <https://gist.github.com/cascadianblue/2856bea128dd1b3f4d0f> that 
> > received some interest from several members of the community, but 
> > neither I nor this proposal were selected for GSoC. A community member 
> > (iirc it was Florian Apolloner) told me to put the proposal in the form 
> > of a DEP. 
>
> I read through the DEP - it's an interesting idea. I'm not seeing 
> anything in the proposal that inherently needs to be part of Django core 
> in order to be useful; it seems that it could just as well be 
> implemented as an installable library. When there's a new feature idea 
> that _can_ live external to Django core, we generally prefer that it 
> _does_ live external to core, at least for a while to prove the design 
> and demonstrate its practical advantage over similar alternatives. 
> Living outside core allows you to iterate much more rapidly on the 
> design, with new releases as often as you need them. 
>
> If in the future it becomes the clear winning implementation of a 
> pattern that is important enough that it should be available to all 
> Django users by default, we may decide to bring it into core. 
>
> Note that this isn't just a theory or something we tell people, it's 
> something that actually happens regularly, including with proposals from 
> core team members. See for example South, django-security, 
> django-transaction-hooks, django-channels... 
>
> So my recommendation is that you implement your proposal as a 
> pip-installable library and advertise it, see whether it gains traction 
> that way, and see what you learn about the design from having it 
> exercised by real users. 
>
> Carl 
>
>

-- 
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/81043deb-ec70-4edc-9fa9-0f7e9861bc65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.