Open philsheard opened 5 years ago
I am also wondering about this. I would like to know what is the best way to support a standalone Django API that does not serve static content and still implement this library's OAuth 2.0 functionality. I think it's pretty common these days to have a separate API and UI application. Would love to use django-oauth-toolkit without having to fork or copy existing views and override functions.
Here was my solution - I added as me class which overrides the form_valid
method to copy the URL params into the body of the response. It's not very intrusive so you could actually implement this within your codebase rather than a fork.
@philsheard did you create a new class to register new applications as well?
No, I just used that custom class within my code when building responses.
Can we get an example of what you did or give us more insight?
Hello, @philsheard. I didn't understand. How can we achieve the alexa integration with your solution? You created a custom view for authorize process?
I use TokenAuthentication
by drf as main oauth system, we are app only. I want to implement consent screen in-app, call the API that @philsheard wrote, but the issue is that the AuthorizationView
is a "django" view and not "drf" view, is there a work around to either (1) make AuthorizationView
a "drf" based view or (2) inject TokenAuthentication
with AuthorizationView
.
I'm using the library to setup an auth server for an Alexa skill. Alexa's "account linking" flow uses OAuth but only accepts tokens and auth codes as JSON in the body of the response [1]:
Is the best option here to fork the library and add a new view based on django-oauth-toolkit/oauth2_provider/views/base.py that returns data as JSON instead of kwargs? This seems a bit brute force and not very DRY so I thought I'd ask what others recommend.
[1] Alexa developer blog post