[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?

[Ryan Hiebert]

On Mar 16, 2016, at 11:55 AM, Connor Boyle <cbo...@macalester.edu> 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/

[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.

[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.

[Collin Anderson]

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

[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.

[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.

[Connor Boyle]

Hello everyone,

I've updated my proposal 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.