By chance I saw this in the authenticate() docs:
https://docs.djangoproject.com/en/2.0/topics/auth/default/#django.contrib.auth.authenticate
Changed in Django 1.11: The optional request argument was added.
Maybe this is the reason why DRF did his own auth handling in the past.
Regards,
Thoma
Am Mittwoch, 3. Januar 2018 17:40:51 UTC+1 schrieb Jason:
>
> Sounds like this is a good use case to integrate DRF to solve multiple
> problems.
>
>
>
I am unsure. I would like to have auth solved by the framework. With
framework I mean django.
--
You received this message because you are sub
Sounds like this is a good use case to integrate DRF to solve multiple
problems.
On Wednesday, January 3, 2018 at 7:57:46 AM UTC-5, guettli wrote:
>
>
>
> Am Dienstag, 2. Januar 2018 13:47:40 UTC+1 schrieb Jason:
>>
>> What you can do is split the backend into a REST API using
>> http://www.dj
Am Dienstag, 2. Januar 2018 13:47:40 UTC+1 schrieb Jason:
>
> What you can do is split the backend into a REST API using
> http://www.django-rest-framework.org/
>
> Refactor the views to share common logic, and you can have your template
> renders bound to one view handler and an api call to an
What you can do is split the backend into a REST API using
http://www.django-rest-framework.org/
Refactor the views to share common logic, and you can have your template
renders bound to one view handler and an api call to another. Configure
your urls.py to have a url like /api/{version}/{res
In one small project all web requests were done by humans in the past.
We used a login form and cookie bases sessions.
Now an API gets created and automated processes access these new URLs.
These processes use a different auth backend.
Now I see two possible solutions:
Solution1: Use one proj
6 matches
Mail list logo
