I'm confused very much, because django-social-auth and python-social-auth seem to be the same, but they are not. In fact python-social-auth is based on django-social-auth.
Now I can't find any resource that compares those two by any means. I can't even find a statement in the python-social-auth docs why they made their own project instead of just working with django-social-auth.
For my project I need to settle on one of those two. Can you give me any help to make this choice?
Think you for your time.
django-social-auth has been deprecated in favor of python-social-auth. It even says this in the django-social-auth README.
python-social-auth was built using django-social-auth as a foundation. The main advantage/difference is that it now supports multiple frameworks.
the newest version is the python-social-auth, and django-socail-auth has been depricated.
python-social-auth is very modular library looking to provide the basics tools to implement social authentication / authorization in Python projects. For that reason, the project is split in smaller components that focus on providing a simpler functionality. Some components are:
social-auth-core Core library that the rest depends on, this contains the basic functionality to establish an authentication/authorization flow with the diferent supported providers.
social-auth-storage-sqlalchemy, social-auth-storage-peewee, social-auth-storage-mongoengine Different storage solutions that can be reused accross the supported frameworks or newer implementations.
social-auth-app-django, social-auth-app-django-mongoengine Django framework integration
social-auth-app-flask, social-auth-app-flask-sqlalchemy, social-auth-app-flask-mongoengine, social-auth-app-flask-peewee Flask framework integration
social-auth-app-pyramid Pyramid framework integration
social-auth-app-cherrypy Cherrypy framework integration
social-auth-app-tornado Tornado framework integration
social-auth-app-webpy Webpy framework integration
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'm used to test Django Rest Framework apps with the test tools available directly in Django and DRF. It's possible to setup a dummy client and expose all the REST methods.
At the same time, I see many posts talking about Postman for API testing. I fail to see where the advantage would be.
Is there any reason for me, a single developer, to use Postman? Or perhaps there is only an advantage for shared projects?
I have been using Flask for Building REST API on the development level. I want to create REST API at Production Level. So which Python web framework would be Best?
These frameworks I saw while searching:
CherryPy
Flask
Django
Pyramid
TurboGears
Pylons
Web2py
Falcon
Bottle
Etc.
Django has a big support for REST API. According to my own experience I'd advice Django.
See more here: https://www.django-rest-framework.org/
For a REST API, I would use FastAPI. It has a strong reputation.
I have used it for several projects, and I like it because it fairly easily lets you do the right thing without much work. For instance, it relies upon pedantic to ensure the proper data types for what you are sending/receiving.
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.
I have followed a number of tutorials and examples on the web to setup and use django piston. They all work flawlessly, until i try to integrate oauth authentication. I have been working against the following examples:
http://blog.carduner.net/2010/01/26/django-piston-and-oauth/
http://github.com/clemesha/django-piston-oauth-example
Yet both of these seem to fail to include examples of the required oauth templates and views. It is quite likely that i'm just not implementing it properly, so any advice would be hugely helpful.
In summary. I have a working django piston setup (that returns / inserts data). What i am struggling with is a definitive guide to integrating oauth authentication. I.e. what do i need to install, which views, settings, url patterns and templates do i need to create?
Thanks
If you're using a released version of Piston, you might be interested in how we implemented OAuth in Snowy, our AGPL web app for Tomboy notes:
http://git.gnome.org/browse/snowy/tree/urls.py#n48
http://git.gnome.org/browse/snowy/tree/api/urls.py
http://git.gnome.org/browse/snowy/tree/api/templates/piston/authorize_token.html
http://git.gnome.org/browse/snowy/tree/api/handlers.py
The OAuth views are bundled with piston (in the released version).
I have yet to upgrade to prencher's improved OAuth fork (which will apparently turn into 0.3 soon?), but here are his instructions if you are using his code:
http://groups.google.com/group/django-piston/msg/5a148c8e33654c5d
(make sure to read all of his responses in that thread, as he makes some clarifications)