Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drf support #13

Open
patvdleer opened this issue Jan 19, 2021 · 3 comments
Open

drf support #13

patvdleer opened this issue Jan 19, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@patvdleer
Copy link

How about DRF/Django Rest Framework support?

I've been looking through the code, would it be a stretch to add a layer for DRF? For TOPT simply provide endpoint for the data/form and serve the image wouldn't be that much of a stretch, I'm not (yet) familiar enough with to inner workings fido/u2f to comment on that part.

patvdleer added a commit to patvdleer/django-multifactor that referenced this issue Jan 20, 2021
@patvdleer
Copy link
Author

taking a shot at it, not ready at all, just the init setup
https://github.com/patvdleer/django-multifactor/tree/drf

@oliwarner
Copy link
Owner

Apologies for ignoring this. I'm keen to keep the project agnostic in terms of structural things like DRF. It raises a lot of challenges:

  • I use sessions heavily to store active factors, redirects. Many DRF users (me included) use JWT or tokens, without handing sessions cookies back. I'm not sure how we reconcile that.
  • The more obvious presentation problems, which I'm even more keen to stay away from. If you're baking this stuff into your frontend, you barely need this project anyway. To keep things simple, we'd let the (eg) SPA know that the user needs to authenticate a secondary factor (via a lightweight API? a custom error code?), the SPA redirect them there, and then redirect them back after they'd authed. But again, that working relies a lot on the state storage.

I don't know what the answer is. Open to suggestions.

@oliwarner oliwarner added the enhancement New feature or request label Nov 1, 2021
@StevenMapes
Copy link
Collaborator

I've been thinking about this on and off for the last few years and it feels like it's not really something this project should tackle as you'd need to enforce DRF devs to work in a specific way.

The closest I thought about getting this working is to have two custom authentication endpoint:

Endpoint one - Authenticates the user, generates a short lived token (30 seconds) which is returned in the response. Note this can not be the normal DRF token as you don't want it to be valid so it would need a custom model.

Endpoint two - Expects the token to be send along with the MFA code, looks up the user from the new model, validates the MFA code, then generates the real DRF token which is returned to the user to use in other requests

It's would need to be extensible as people create custom auth tokens all the time, I for examples have expiring tokens for some DRF projects with different expiry rate.

Just thought I'd put my thoughts down as a comment since I come back to this thread every few months and keep thinking about posting this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants