Proposal: Implement CORS & OAuth/OAuth2

[Christian Schmitt]

Hello, I'm Christian Schmitt and in my Company we are working with AngularJS and Django.
Currently we are working on a application that makes heavy usage of Django HTTP Rest Framework.

Since the web is growing and more and more the web develops from a pure HTTP Response / Request Web to a more Heavy Client-side Web with websockets or JSON Response data.

With the introduction of Django Class-Based-Views it's even more easy to turn Django into a really really good solution for APIs. 

But still some things are missing. 

I hope i could explain them and tell them why django needs them.

1. CORS:

At the moment every request Django does needs to be on the same ORIGIN. Let's explain this on a development environment.

- Django runs on localhost:8000

- a second client either javascript (running on localhost:9000) or let it be a android application

Now when the Javascript client or the Android Application making requests to localhost:8000 they will get an error that they don't have access to localhost:800 since they are not in the Access-Control-Allow-Origin header.

(http://en.wikipedia.org/wiki/Cross-origin_resource_sharing)

This is very sad and django has no current solution for this. Maybe this would also be cool to be configured in the Django-admin

2. OAuth/OAuth2 support:

Currently Django only supports authentication with the inbuilt HTTP Basic Auth.

Why I want django to support OAuth? Currently take a look at Google at Django OAuth or even the Django documentation: (https://docs.djangoproject.com/en/dev/topics/auth/#overview) There could be OAuth in a 3rd party package.

But now let's take a closer look, how many 3rd party oauth package does exists?

> https://www.djangopackages.com/grids/g/oauth/

Currently this site tells us that there are 7 packages. And thus aren't all packages.

I think it would be great to move one of them in contrib, that the development of these great tools could be coordinated and only one or two good solutions will stay alive while people could contribute to the 'best' solutions.

Since its always a pain for developers to use packages when there are so many. It leads to fragmentation. I mean what happens when i then need to fork, since some features are missing on every package? then we have another solution and most of the time the fork won't get pulled into the main version, so there will be a new package alive.

Currently I think that we should take a look in the future and maybe add more packages to contrib that solves the problem of Django and the future web. Lot's of things change with the bigger support of html5 support in browsers.

And with new tools like yeoman (http://yeoman.io/) and angularjs (http://angularjs.org/) or backbonejs (http://backbonejs.org/) or even other tools as described here: http://net.tutsplus.com/articles/web-roundups/20-javascript-frameworks-worth-checking-out/

The web will change and django is an ecosystem and i think its a must that the ecosystem will evolve and support even more than plain html in the future.

Conclusion:

Even for REST Architecture Django is a great tool and some companies making heavy usage of Django REST. One of the greatest companies that use it, is INSTAGRAM. They have a pure Django based backend while connecting thousands of clients to a Django Backend.

Also the introduction of CBV is a huge step forwards to support this kind of architecture. The only thing that Django misses are better JSON/XML/YAML support for input/output data and data exchange between clients, but i think currently tastypie and django http rest framework are good solutions and they aren't that much fragmented.

Also there are other good solutions whats needed: https://groups.google.com/forum/?fromgroups#!searchin/django-developers/rest/django-developers/oozPnQrbrhA/NSNECwneEtIJ

And many many more.

[Aymeric Augustin]

Hi Christian,

On 28 juil. 2013, at 16:20, Christian Schmitt <c.sc...@briefdomain.de> wrote:
> 1. CORS:
> (…)

> This is very sad and django has no current solution for this. Maybe this would also be cool to be configured in the Django-admin

Django provides an API to set HTTP headers in responses. I don't know what higher-level abstraction would help deal with CORS, but in all cases, it's a security-related configuration. As such, it belongs in the settings, not in the admin. (In fact, it may belong in the web server configuration, not in Django; I can't say for sure!)

There's at least one third party app designed to help on this front: https://pypi.python.org/pypi/django-cors-headers.

If you want to bring improvements to Django in this area, you should write a concrete API proposal. You can safely assume that readers of this mailing list have good grasp of the state of the web :)

> 2. OAuth/OAuth2 support:
> (…)

> I think it would be great to move one of them in contrib, that the development of these great tools could be coordinated and only one or two good solutions will stay alive while people could contribute to the 'best' solutions.

If my informations are correct, oauthlib and django-oauth-toolkit are taking the lead, at least on the OAuth2 front.

Given my experience with OAuth, I'm not looking forwards to maintain an implementation in Django :/ It's a great example of a feature that can be maintained outside of Django itself.

> Since its always a pain for developers to use packages when there are so many. It leads to fragmentation. I mean what happens when i then need to fork, since some features are missing on every package? then we have another solution and most of the time the fork won't get pulled into the main version, so there will be a new package alive.

I understand that fragmentation causes frustration. However merging packages into Django isn't guaranteed to help. If some features are missing, it'll take much longer to add them in Django than in a third-party package.

Python's standard library is where packages go to die. To a lesser extent, that's also true of django.contrib.

> Currently I think that we should take a look in the future and maybe add more packages to contrib that solves the problem of Django and the future web.

I have to disagree. The ecosystem of third-party packages is much more instrumental to the success of Django than contrib apps (with the exception of the admin). Blessing a solution stifles competition, hinders progress, and makes it much harder for (possibly better) alternatives to emerge. That's why the current trend is to slim down contrib.

--
Aymeric.

[Daniel Greenfeld]

I'm going to give a strong +1 here. In fact, can I inflate that to +100?

As soon as something gets into Django itself then any improvements or API changes occur at a much slower pace. This is out of the necessity of providing a stable interface for developers. This becomes incredibly problematic when you need to have changes to reflect new developments in authentication and authorization. While things have currently 'stabilized' on OAuth 1 and OAuth 2, other systems may suddenly leap to the fore. In addition, major implementors of them (Twitter, Facebook, et al) are know to change things with little to no warning. Finally, there is always the risk of a security breach being discovered.

Putting this into contrib means that the community cannot quickly adapt to the changes in the authentication landscape. If Django had a faster release pattern that might not be a problem, but I'm not so sure about it.

As for the Django Packages site, we've been slowly working on fixing some bugs and bitrot. Once we've gotten the priority items done we plan to implement a way to promote and demote packages which will make grids much more useful. We've had this request several times for security-related packages, database connectors, and other things. We're not sure about the API yet, but there you go.

-- 

'Knowledge is Power'

Daniel Greenfeld

Principal at Cartwheel Web; co-author of Two Scoops of Django; Maintainer of Django Packages

cartwheelweb.com | pydanny.com | django.2scoops.org