I want some advice on choosing right package in a REST Api django project
For authentication:Which one of below I should choose ?
django-oauth-toolkit: seems to be the most robust and recommended oauth library for DRF. This do not have account management. How can i implement account management with this package? If yes, can I get some guide.
django-rest-auth: API endpoints for authentication, and basic account management for DRF. But seems not as robust as django-oauth as django-oauth allows token expiery etc. or i am missing some feature of rest-auth
For authorisation: I will be going for django-guardian over django-role-permission. Later seems more like back end utility to control user roles.
My deep desire is to use oauth-toolkit but it does not have basic user management. On the contrary rest-auth has user management but lacks (seems to be) roubustness of oauth.
Please help me make a choice.
I came to understand that DRF supports builtin support for OAuth2 and provides token utilising 'provider.oauth2'dependency hence django-oauth-toolkit could be avoided just in case.
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.OAuth2Authentication',
),
Thanks every one for your interest.
Django rest auth amounts to a small set of API views around django-allauth which is (according to github usage stats) much more used than oauth-toolkit.
allauth is pretty great and has a long list of available providers. Adding a new one is very easy and can nearly be completed 100% through the admin interface.
rest_auth essentially wraps django allauth to make it available via API. Where rest_auth falls short, it is fairly easy to implement what you need to work directly with allauth. If you need jwt support with rest_auth they recommend another 3rd party library.
The biggest problem with rest_auth we've run into is that the documentation is just OK and there are many open issues in the repo that should be closed with more clear resolution, there is a lot of misinformation in the issues.
Looking forward to resolving some of that confusion by inquiring as to the State of rest_auth
As far as your need for user management goes, django user management is robust as is.
Related
I am a nodejs developer but currently migrating to django(being a python lover). I am trying to implement OAuth2 in Django Rest Framework but I don't know how to start.
In nodejs, there is passportjs library which is well maintained, and it's got stratigies for every possible authentication type. What about django rest framework ? User name/password auth seems straightforward but oauth2 is not well covered.
In DRF docs here, It mentions two libraries for oauth. The first is django-oauth-toolkit which is well maintained but after going through docs, I didn't seem to understand much, it doesn't even talk about googl/facebook oauth. I am not sure what it is used for, anyway. The second one is django-rest-framework-social-oauth2 which seems to be straightforward but it's not been touched for over a year, it's probably not maintained any more.
So, How do you guys do oauth2 in your DRF projects ?
I hope you have solved this already. You can check my repo: It offers a simple way of authenticating against major ouath2 vendors. Here it is https://github.com/wagnerdelima/drf-social-oauth2.
You can also check my other repo https://github.com/wagnerdelima/facebook_setup. It integrates https://github.com/wagnerdelima/drf-social-oauth2 as an example to make it easy for newcomers.
I am a beginner in the world of the OAuth2.0 and OpenID Protocols. I would like to implement a custom server - provider for multiple applications. So, to use it for Single Sign-On (SSO). I would like to work with python. Till now I have found four packages, for an OAuth2.0 and an OpenID Connect server implementation, in Python: pyoidc, django-oidc-provider, Django OAuth Toolkit (DOT) by OAuthlib and Authlib. I tried to read and understand pyoidc, but it was not so helpful and easy, basic things were missing. I have tried django-oidc-provider and I was really satisfied, and the whole implementation was really easy. So, after those trials, I am left with Django OAuth Toolkit (by OAuthlib) and Authlib. Has anyone tried them? Are these packages the same? Is Authlib an updated version of the OAuthlib library? The only information I know till now, is that Flask-OAuthlib is deprecated, and Authlib is was its new version.
*Every answer or advice or personal experience would be really helpful and always appreciated!
Thank you again for your help.
After some research, I concluded to work generally with JWTs. As before, I would like to work with a GraphQL API, so I am searching for solutions about JWT authentication on it. I maybe use Passport.js (passport-jwt) or something else for Python. All the libraries mentioned above possibly will be not used.
I will just redirect the user to my main application, authenticate them with JWT, and then return the JWT back to the application. In the future and after deployment, I might also implement an OAuth2.0 provider for my website. Although those packages did not really help me, I would recommend Django OAuth Toolkit (DOT) and django-oidc-provider to others. But, also I learned that django-oidc-provider only supports the implementation of a small and simple OAuth2.0 provider. Django OAuth Toolkit comes with lots of options for implementing an advanced OAuth2.0 Authentication Server (AS), including Authorization Code flow with PKCE (Proof Key with Code Exchange), which is the most secure flow. It is also scalable and has great documentation with lots of customizations if you want.
*I sent an email to the support of Authlib, and of course no one has answered to me after a week.
I understand that full django can be used out of the box with CloudSQL. But I'm interested in using HRD. I'd like to learn more about what percentage of django can be used with nonrel. Does middleware work? How about other features of the framework like i18n, forms, etc. Also does nonrel work with NDB?
The background here is that I've even using webapp2 and before that webapp and find them great until your project gets bigger. So for this project I'm interested to reevaluate other options.
The big limitation is that the datastore doesn't do JOINs, so anything that uses JOINS, like many-to-many relations won't work.
Any packages/middleware that uses many-to-many won't work, but others will.
For example, the sessions/auth middleware will work. But if you use permissions with auth, it won't. If you use the admin pages for auth, they use permissions, so you'll have some trouble with those too.
i8n works.
forms work.
nonrel does not work with ndb.
I don't know what you mean by "until your project gets bigger". django-nonrel won't help with the size of your app.
In my opinion there's two big reasons to use nonrel:
You're non-committal about App Engine. Nonrel potentially allows you to move to MongoDB as a backend.
You want to use django packages for "free". For example, I used tastypie for a REST API, and django-social-auth to get OAuth for FB/Twitter logins with very little effort. (On the flip side, with 1.7.0, they've addressed the REST API with endpoints)
I would like to create an oauth (REST) API the same way Twitter or Foursquare does.
I found this website http://djangopackages.com/ which is really great and has several packages but I would like some opinions on which is the best package, etc...
I would like, for example, let people to allow permission to 3rd party apps to access their data (Using API Keys, etc...)
Thanks a lot!
Django is a wonderful web framework. It helpes you in many ways making rich web applications. It helps you starting in form handling and ending in templating.
However in your case if your intension is just to make an awesome API such as of Twitter or Foursquare, you have to ask yourself if you need all this help Django provides. For example, are you ever going to use any templates in the API or process a for submittions. The answer is probably not...
So if you need a very flexible framework to developer an API, I would highly recommend to take a look into Pyramid. It is very similar to Django, however does not have all this extra cludder which is not necessary for an API.
However if your application needs both a rich user interface and an API or you just want to use Django, like Ulusses suggested, then I think TastyPie is for you. It is a great library where you can have a running API in no time. I use it all the time and it is very flexible. ReadTheDocs uses tastypie.
Another API lib is piston. I haven't used it so can't judge if its better or worse then tastypie. Bitbucket however uses it.
You can check out https://github.com/toastdriven/django-tastypie or https://bitbucket.org/jespern/django-piston/wiki/Home.
You can achieve what you want with both, check out on the documentation the one that suits you best.
I use Django REST framework. It is awesome.
Piston is dead. Tastypie is awesone, but works with Django only. There are pros and cons with Django as well as Pyramid. If you need great ORM, sqlalchemy is only one, and there is no good example of using it with Django, so in this case you have Flask, Bottle or Pyramid. Django ORM is really not at that par.
If you choose Pyramid, you will have to write a lot of things, and the framework is just skinned boneless cat. You need to assemble and configure every block, seems frustrating to many including me.
We're looking for a general RESTful API solution for our Django project. We would use the API at first for Ajax calls on the web site and later for mobile apps, external apps and things like that.
I found two modules which seem to be widely used. django-piston and django-tastypie
From what I read, piston seems to be older and thus more mature but maybe a bit outdated?!
While tastypie is relatively new and nicely documented.
What would be the best thing to go with? django-piston or django-tastypie?
Important for us (ordered by priority): Continuous maintenance of the source, documentation, stability, ease of use.
EDIT (2013 Jul 16th):
Now over a year later we have a clear winner. At first we went with tastypie. Which we kinda liked. But after half a year or so we switched to the then upcoming django-rest-framework and never looked back.
What we like most about it:
Nice documentation
Active community
Clean design (build upon django's class based views)
Browsable API for development and debugging
We rely on the API heavily so support (in the future) is one of our main concerns. We met the maintainer - Tom Christie - (on and offline) and he seems very committed to the project. So we feel very comfortable using the django-rest-framework.
A good resource to compare them is http://www.djangopackages.com/grids/g/api/
Django-tastypie sure is the save choice right now.
Personally I'd advocate a look at django-rest-framework if you use django 1.3, because it uses the new class based views. djangopackages.com's comparison page shows it has good participation and activity. And, wow, it sure has a nice browsable interface to the API.
I have no experience with this, but I trust Pydanny in this:
django-piston has been barely supported for nearly two years. That is
an eternity, and the number of forks to address multiple issues is a
cause for alarm. Because of that, in it's place at this time I
recommend django-tastypie. It is up-to-date, has very good
documentation, supports OAUTH, and scored second place in the Django
Packages thunderdome (it got nearly 3x as many points!). Another tool
to consider is Django Rest Framework, which is as good as
django-tastypie but lacks the OAUTH support.
On the django-piston front, Joshua Ginsberg has taken over the reins
and we should hopefully see some movement again. In which case I'll be
able to remove this section of the blog post.
from Pydanny's blog.
Having implemented API's with django Piston, tastypie and django webmachine Django tastypie rocks! Having said that, I think that while tastypie is really good when your API is modelled close to your models, it's a little bit more complicated to do things once you want to move out of the box. There are workarounds to some issues, with others you have to do more bending than building. It will, probably, still cover 90% of django use cases.
Afaik Webmachine was modelled after the popular erlang webmachine, but hasn't been very active lately. So that leaves piston, which is picking up some activity, and tastypie, that has a lot of momentum and activity. Piston is a bit more flexible, but tastypie is moving very fast and in my opinion has a really easy API.
My recommendation would be to quicky implement a prototype of the API in tastypie, and see if it covers what you want to do.
Django REST framework 2.0 was anounced in Oct 2012 and now supports OAuth out of the box. What I really like is the Web browseable API, which is really helpful when developing your API, but also when someone implements your API. It's kind of comparable with using the Django admin site for inspecting your models' structure and data, but then for your API. Also the documentation is very good.
From their website:
Django REST framework is a powerful and flexible toolkit that makes it
easy to build Web APIs.
Some reasons you might want to use REST framework:
The Web browseable API is a huge usability win for your developers.
Authentication policies including OAuth1a and OAuth2 out of the box.
Serialization that supports both ORM and non-ORM data sources.
Customizable all the way down - just use regular function-based views if you don't need the more powerful features.
Extensive documentation, and great community support.
Check out their Quickstart guide to get a quick idea of how it works.