Proposal: Implement CORS & OAuth/OAuth2
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. -- 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: Proposal: Implement CORS & OAuth/OAuth2
Hi Christian, On 28 juil. 2013, at 16:20, Christian Schmitt 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. -- 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: Composite fields -- (ir)regular status report #3
> I did a quick review of the patch and didn't see anything that jumped out. > BTW when you want to merge a part of your work, please open a pull request. > Reviewing is much easier that way. I just opened a pull request [1]. The branch is up to date and it does not add any test failures that are not already there on master (I get 3 failures on master with anything but SQLite.) It implements automatic auxiliary field creation as well as manual auxiliary fields. I should probably add tests for select_related and defer/only with custom auxiliary fields, which I'll try to do tomorrow. Michal [1] https://github.com/django/django/pull/1407 signature.asc Description: Digital signature
Re: html email through from django.core.mail.send_mail and html email for password resets?
Hi Justin, Correct - this should be handled as two separate tickets. If the patch for one ticket depends on a second, it's fine to have that dependency in the patches -- just note in the comments for the ticket when you upload your patch, or in the comment for the pull request. Essentially, we just need to make sure that whoever reviews the second patch knows that the other patch needs to be reviewed and integrated first. Plus, if you put in a link the other way as well, the person who reviews the first patch will know that there's a second patch in a closely related area that would be worth reviewing while they're in the same mental space. Yours, Russ Magee %-) On Sun, Jul 28, 2013 at 11:54 AM, Justin Michalicek wrote: > Awesome, thank you. I am guessing it is preferred that these be done as > two separate tickets and patches since they are technically separate > features. I'm not seeing an obvious way to mark one as relying on another, > though. Should I just note in the trac ticket for #2 that it relies on #1 > when I create the tickets, wait for #1 to be accepted and merged then do > the PasswordResetForm, or just do them both in one feature branch and pull > request due to the PasswordResetForm change relying on the change to > send_mail()? > > > On Saturday, July 27, 2013 11:17:48 AM UTC-4, Justin Michalicek wrote: >> >> I would like to make my first contribution to the Django code, but these >> both are pretty easy and at least to me seem pretty obvious, so I thought >> there might be some good reason they have not yet already been done. >> Depending on the response, I would do these in different ways as well, so I >> want to check here before getting to work. >> >> 1) Adding an html_message parameter to django.core.mail.send_mail(), the >> same as mail_admins() and mail_managers() have. Seems useful and like a >> good idea, but it's dead simple, so it also seems like it would already be >> there unless it for some reason had been decided that this is absolutely >> not going to happen. >> >> 2) Adding the ability for django.contrib.auth.views.**password_reset() >> to take an optional parameter for an html email template as well as >> django.contrib.auth.forms. >> >> PasswordResetForm.save() so that html password reset emails may be sent. >> Again, simple enough that I worry that there's a reason this isn't already >> done that I'm unaware of. >> It is also somewhat dependent on #1 there in that either #1 has to be done >> first or this has to be done by using EmailMultiAlternatives directly rather >> than send_mail(). >> >> Any input on if I should proceed or if there's some reason I should not >> touch these would be greatly appreciated. I'd love to make a contribution >> to Django and these look >> like a safe, simple, and useful place to start. >> >> -- > 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. > > > -- 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: html email through from django.core.mail.send_mail and html email for password resets?
Excellent, thanks again! First pull request is in along with a trac ticket. I should get a chance to knock out the password reset one some time in the next couple of days as well. It's a quick change and I've done most of it with subclasses on personal projects previously. On Sunday, July 28, 2013 8:38:29 PM UTC-4, Russell Keith-Magee wrote: > > Hi Justin, > > Correct - this should be handled as two separate tickets. > > If the patch for one ticket depends on a second, it's fine to have that > dependency in the patches -- just note in the comments for the ticket when > you upload your patch, or in the comment for the pull request. Essentially, > we just need to make sure that whoever reviews the second patch knows that > the other patch needs to be reviewed and integrated first. Plus, if you put > in a link the other way as well, the person who reviews the first patch > will know that there's a second patch in a closely related area that would > be worth reviewing while they're in the same mental space. > > Yours, > Russ Magee %-) > > On Sun, Jul 28, 2013 at 11:54 AM, Justin Michalicek > > > wrote: > >> Awesome, thank you. I am guessing it is preferred that these be done as >> two separate tickets and patches since they are technically separate >> features. I'm not seeing an obvious way to mark one as relying on another, >> though. Should I just note in the trac ticket for #2 that it relies on #1 >> when I create the tickets, wait for #1 to be accepted and merged then do >> the PasswordResetForm, or just do them both in one feature branch and pull >> request due to the PasswordResetForm change relying on the change to >> send_mail()? >> >> >> On Saturday, July 27, 2013 11:17:48 AM UTC-4, Justin Michalicek wrote: >>> >>> I would like to make my first contribution to the Django code, but these >>> both are pretty easy and at least to me seem pretty obvious, so I thought >>> there might be some good reason they have not yet already been done. >>> Depending on the response, I would do these in different ways as well, so I >>> want to check here before getting to work. >>> >>> 1) Adding an html_message parameter to django.core.mail.send_mail(), the >>> same as mail_admins() and mail_managers() have. Seems useful and like a >>> good idea, but it's dead simple, so it also seems like it would already be >>> there unless it for some reason had been decided that this is absolutely >>> not going to happen. >>> >>> 2) Adding the ability for django.contrib.auth.views.**password_reset() >>> to take an optional parameter for an html email template as well as >>> django.contrib.auth.forms. >>> >>> PasswordResetForm.save() so that html password reset emails may be sent. >>> Again, simple enough that I worry that there's a reason this isn't already >>> done that I'm unaware of. >>> >>> It is also somewhat dependent on #1 there in that either #1 has to be done >>> first or this has to be done by using EmailMultiAlternatives directly >>> rather than send_mail(). >>> >>> Any input on if I should proceed or if there's some reason I should not >>> touch these would be greatly appreciated. I'd love to make a contribution >>> to Django and these look >>> >>> like a safe, simple, and useful place to start. >>> >>> -- >> 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-develop...@googlegroups.com . >> To post to this group, send email to >> django-d...@googlegroups.com >> . >> Visit this group at http://groups.google.com/group/django-developers. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- 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.
