Why was auth re-invented? What was missing in django?
62 views
Skip to first unread message
Thomas Güttler
Jan 19, 2018, 3:44:52 AM1/19/18
to Django REST framework
Why was auth re-invented in Django-Rest-Framework?
What was missing in django?
My problem: We have some APIs which use DRF and some do not use DRF.
Everything works. But the design is ugly since we use different solutions for the same goal.
This makes our software more complicated and developers waste time.
I guess there were valid reasons why this was done.
Why not improve django, this way everybody (yes, there are people which do not use DRF) could benefit.
What was missing in django?
My problem: We have some APIs which use DRF and some do not use DRF.
Everything works. But the design is ugly since we use different solutions for the same goal.
This makes our software more complicated and developers waste time.
I guess there were valid reasons why this was done.
Why not improve django, this way everybody (yes, there are people which do not use DRF) could benefit.
Jason
Jan 19, 2018, 8:45:30 AM1/19/18
to Django REST framework
Knowing some of the backstory would be nice for me as well
However, why this wasn't ported to Django core as a whole? Most likely because it broke things on that side and django-core developers weren't able to integrate while maintaining compatibility with other parts of the project.
Xavier Ordoquy
Jan 19, 2018, 9:39:28 AM1/19/18
to Django REST framework
Le vendredi 19 janvier 2018 09:44:52 UTC+1, Thomas Güttler a écrit :
Why was auth re-invented in Django-Rest-Framework?
What was missing in django?
I don't know the initial reasons but from my experience, Django has a couple of non obvious implicit constraints on the authentication / permission that are fine for websites but some APIs require more flexibility.
To name a few:
- No clear separation of concerns between authentication and permissions.
- It's not supposed to have different authentication schemes across views.
- Permissions are checked out of the context of the request.
- Permissions are linked to a model, not to a representation (the R of ReST).
My problem: We have some APIs which use DRF and some do not use DRF.
Everything works. But the design is ugly since we use different solutions for the same goal.
This makes our software more complicated and developers waste time.
I'm not sure I get your point here.
DRF is loosely coupled. You are free not to use DRF authentication / permission and fall back on Django's.
I guess there were valid reasons why this was done.
Why not improve django, this way everybody (yes, there are people which do not use DRF) could benefit.
That would indeed be nice to start bridging that part with Django.
Unless this is a priority for someone it'll likely remain in its current state.
Xavier.
Thomas Güttler
Jan 22, 2018, 8:16:52 AM1/22/18
to Django REST framework
I am happy that my issue was understood. That's all I wanted.
Thank you for your reply.
Tom Christie
Jan 25, 2018, 4:10:14 PM1/25/18
to Django REST framework
Couple of reasons why we needed to do it.
1. Allow auth to be controlled per-view.
2. Ensure that CSRF is only required for session authentication. (While still supporting both session and non-session auth)
Something similar could be ported into Django core, the question there is less “would that be reasonable” and more “who’s motivated to take that on?” It’s mean plenty of work, plus questions about the upgrade path from REST framework.
1. Allow auth to be controlled per-view.
2. Ensure that CSRF is only required for session authentication. (While still supporting both session and non-session auth)
Something similar could be ported into Django core, the question there is less “would that be reasonable” and more “who’s motivated to take that on?” It’s mean plenty of work, plus questions about the upgrade path from REST framework.
Reply all
Reply to author
Forward
0 new messages