Merge functionality from django-rest-auth to provide JSON compatible APIs?

[sww314]

I have used allauth on multiple projects, but increasing I find it difficult to connect with mobile applications and modern web projects because the response objects are HTML responses instead of more modern responses in JSON (or your even better your preferred rendering of the data like -> http://www.django-rest-framework.org/api-guide/renderers/#how-the-renderer-is-determined)

This issue was brought up in #360 and is several years old. There is a 3rd party library that relies on allauth and tries to add on the capability: https://github.com/Tivix/django-rest-auth

However, django-rest-auth lacks in documentation (https://github.com/Tivix/django-rest-auth/issues/263, https://github.com/Tivix/django-rest-auth/issues/292) and quickly runs into roadblocks where the code needs access or modify allauth internals (https://github.com/Tivix/django-rest-auth/issues/278).

Is there interest in a pull request to add this capability?

[pennersr]

There is already basic AJAX support built into the existing allauth endpoints. For example, when doing an AJAX POST request to the password change form, you'll get a JSON response in return.

This has recently (commit 8f71ccbc1ea6a301f6cbdeba742dc5a23f1a9862) been extended with adding support for AJAX GET requests as well. So, an AJAX GET request to the e-mail management view will return a JSON response containing all the e-mail addresses setup for the user, and so on.

So far, the current approach has avoided setting up dedicated API/XHR endpoints. I must admit, I have no experience with the other packages you are referring to, but I am definitely interested in offering a decent AJAX experience out of the box...

Is there interest in a pull request to add this capability?

I think this needs a bit more thought and studying, I still need to sort out what is missing from the current allauth approach compared to the ones you mentioned.

[sww314]

@pennersr I will try to layout what I think it missing. I have re-written chunks of allauth in a couple of projects to deal with limitations before.

[pennersr]

Please do provide feedback on what you all think is missing.

As for a bit more background information: adding dedicated XHR/API endpoints is difficult to get right. For example, for the email management screen, one would expect that you can send an HTTP DELETE request to /xhr/emailaddresses/123/ to remove an e-mail address from the list. Others would not be pleased by any of this and expect a full-blown GraphQL endpoint. That's the reason I have avoided the issue altogether and opted for making the existing end-points XHR aware. On the implementation side this adds minimal bloat to allauth, and the XHR responses can be fully overriden via the adapter.

[lukeburden]

It makes sense to me to bring django-rest-auth into the allauth project. The interface between these projects is shaky, and there are versioning concerns. I don't think there are many projects out there that are purely web/mobile web these days. It'd be amazing to see allauth embrace this fact, remain highly relevant, and provide first-class API endpoints.

I've done some work on extending django-rest-auth to provide a "connect-only" endpoint, which I would happily provide.

[pennersr]

Before taking any action I would first like to inventorise what scenario's need to be covered. See my comment above.

[okc0mputer]

The main problem i see with integrating allauth and rest-auth is the increased possibility of changes in one project breaking the other (mainly a change in allauth possibly breaks rest-auth, or just changes in expected functionality). rest-auth seems to be using allauth as a way around creating certain default auth endpoints, and integrating the two projects doesn't seem to be the right action, since from what I can see, the rest project isn't that interested in developer ease of use.

[chubz]

I saw it somehow as an app that carries integration of allauth default behavior and flows done in DRF APIViews/routers etc. It seems like a natural fit to provide such an implementation considering a lot of projects are moving to REST APIs as a default to serve both web(js) and mobile(native) clients. This app then could be added if allauth is used with DRF on a project much like allauth.socialaccount is added currently.

As for GraphQL that seems to me as not in this scope since the mapping or processes would be different.

As for the scope of functionalities, it seems pretty similar to what is currently being done: Registration Login Logout Account/Email management Social

[lazar-eric]

Hi, I am sort of a beginner with Python and DRF. Have you updated allauth to have API endpoints, for login, social etc. as talked above? Or should I use django-rest-auth. I want to have Angular 5 on frontend, so it would be convenient to manage users, and tokens, through an API endpoints. Thank you!

[sww314]

@lazar-eric you need django-rest-auth still.

[lazar-eric]

Thank you, I already created entire user/profile management REST micro service. Here you go, maybe its of some help to you: https://github.com/lazar-eric/authentication

[JulianTenschert]

Are there any news on this topic?

[pennersr]

No news from this side. So far this issue is not really actionable. My callout above asking for concrete scenarios to be covered has not been answered...

[chubz]

I bet this must seem daft, but can you just quick throw some scenario expectations. Something along the lines of what functionalities should be covered eg. registration (with optional activation), Login/Logout, Email Confirmation, Password reset etc? Or more of a full scenario like: A user makes a call to regiter with (username, or email, and password, receives an activation with a code he needs to enter when he logs in, or on a separate sceen) info to register an account?

[pennersr]

@chubz The existing views are already AJAX capable. There is nothing preventing you from posting data to these views from within a single-page app.

[chubz]

I'm thinking more in line with: If you have support built in for DRF it might make it an easier integration and possible extension of functionality for projects using both packages.

DRF offers other things besides views/serializers. Also makes for responses to be pluggable with DRF renderer eco system, not just ajax->json scheme. Also there is permissioning, validators, throttling, versioning etc.

Having support for ajax->json is great and should not be removed since it is a sane default, but direct official integration with DRF in allauth would provide for saner defaults, docs and a better experience for people using both packages, I think that there are pain points with rest auth that could be overcome by adapting it to allauth in an official manner.

[pennersr]

@chubz Bringing in DRF involves making all sorts of opinionated choices, which is something that is best served in a separate / standalone project built on top of allauth. The mere act of choosing DRF is already something not everyone agrees on.

If you want to go that route, please contribute to https://github.com/Tivix/django-rest-auth. Merging rest-auth here is not automagically going to fix lack of documentation nor solve bugs. These issues can be addressed in separate repos just as well.

Please do call out here if there is anything that can be changed to make life easier in django-rest-auth and further upstream.

The current status is that the views are already AJAX capable and the resulting JSON can be tweaked at will (see adapter method: ajax_response). The completeness of all of this may still be an issue, and I am keeping this ticket open to see if there are concrete issues people are running into. So far none have come up. But, DRF is unlikely to be integrated any time soon.

[chubz]

Thanks for a prompt and clear response. I see the reasoning behind it and respect that.

[zbyte64]

I don't think baking in DRF is the was to go either. Personally I am interested in integration with django-graphene. Since most of the functionality is contained in forms or the adapter API I found integrating with django-graphene to be adequate.

[johnwyles]

@zbyte64 I realize your comment is almost a year old but do you have a quickstart guide or instructions on integrating graphene + allauth? I can glean from a few searches it looks like re-wiring the logic in views / forms into graphql mutations but just starting out with all of that is a bit overwhelming so any guidance you could provide or documentation you have read would be massively beneficial

[zbyte64]

@johnwyles I don't have anything specific written yet for graphene & allauth, that might make a good project... Anyhow the closest thing I have is an example of using an auth form with graphene: https://github.com/zbyte64/real-world-graphql-with-django#mutations

[mikhail-skorikov]

Hello, I'm not sure if this is the right place to ask, I'm new to everything, but does the AJAX capability extend to social logins? And if so, how can it be used for say a facebook login and signup using API calls? I would like to avoid using another library to extend the feature, but if there's no easy way to implement it, I'd rather sacrifice that wish and go with the rest-auth library. Considering the lack of word on this topic, I'm guessing I missed something fundamental...

[pennersr]

Closing -- see https://github.com/pennersr/django-allauth/issues/1678#issuecomment-400631876

[HasanAshab]

Can I do Token Auth with Allauth?? As Session management may be bit complex for mobile ajax

[pennersr]

See: https://allauth.org/docs/draft-api/#section/App-Usage

[HasanAshab]

@pennersr another prob is rate limiting

when a req is throttled, AllAuth tries to render 429 err template.

[pennersr]

@HasanAshab If you are having problems with django-rest-auth, please try out the new headless functionality available over at the feat-headless branch. It is powering the demo over here: https://react.demo.allauth.org/ If you have any feedback regarding the headless functionality, please report over at #360.

[HasanAshab]

@pennersr Thats really good :) should I use this branch on my prod app??

[pennersr]

https://github.com/pennersr/django-allauth/issues/360#issuecomment-2043412945

So, if you are planning on moving over anyway, it would be good if you could move your app only on a development branch so that more feedback is received on this end.

[HasanAshab]

Great! I will integrate it and will give feedback :)