Authentication and Sign Up Strategy (Was Issue #101)

[BethanyG]

Moving this from issue to discussion, since this talks more about different areas of research/questions/strategy, and less about implementation details. Initially ported from front-end discussion codebuddies/frontend#77.

[BethanyG]

(from my original reply on Mar 7)

As far as I understand, Django uses a username as an account identifier, and an email is not required, but a strong password (we can determine the criteria for what constitutes strong) is required. We can require an email...but we should discuss if we want to do that, and if we want to always persist it. That would also require a codebuddies API change.

Just for some touchpoints: here is the Django Auth Docs.

Our current setup includes:

1. A custom user model, where we can add fields we want to track outside of the ones provided by the default Django user model.

2. The default password storage, based on PBKDF2 with a SHA256 hash

3. The default authentication backend and the django-allauth AuthenticationBackend - "social auth" - although we are not currently using it. Here are more available authentication backends.

4. Django DRF, which has it's own methods and settings for authentication. Our current setting is rest_framework.permissions.IsAuthenticated.

5. Django-rest-framework-jwt, to provide JWT tokens once a user is authenticated through the stack above. django-rest-framework-jwt on GitHub

Some potential libraries/extensions:

1. django-authlib, which can provide an additional layer over the above stack so that users do not have a password, but are rather sent a cryptographically signed link via email, or are "authed" through a third party providers email.

2. django-sesame, which can provide "magic links" that include a token. There are multiple caveats here, one of which is no clear support of DRF or JWT as we currently have it implemented. There are also multiple security concerns with token issuance and URL interception. Here is a how-to I quickly dug up.

3. I haven't dug into this at all, but here is a blog post on secret links and security in Django on a per-URL or view basis.

4. Django does provide for "generating" passwords via the make_password() function, so we could call that to generate a password for a user.

5. django-extensions - which we use in our dev env, but not in production, can also be used to generate passwords.

[BethanyG]

(@lpatmo original reply on Mar 7)

A sixth library we can add to the list for magic links:

drfpasswordless (found on the bottom of the DRF page)

[BethanyG]

Issues linked/affected by this discussion:

• [Discussion] New User Registration Confirmation emails & Associated Changes Needed #110
• [User Registration] Make email required on backend #111 (closed)
• [Users] Change Email to Required Field for User Registration #112
• [User Registration] JWT Serializer Changes in Support of User Email Validation #113
• [User Registration] Changes to userauth App in Support of Email Validation #114
• [User Registration] Need to Define JSON Spec for User Profile #118

[lpatmo]

A few clarification questions:

1. The main goal is still to get email verification working with our current auth setup, right? Since at the moment, when users are registered, they're automatically registered and could have entered anyone's (a stranger's) email and signed that person up.

2. Our current setup involves a custom user model... but with allauth, users are stored in the account_ tables
   

Am I undertanding right that we're considering "switching" to using allauth (for pure email, not necessarily social media auth right now) which will entail that user info will be stored in the account_ tables?

[BethanyG]

Wrote this below as well. Putting it here for context.

To get back to the original question:

1. When a user registers using the /rest-auth/registration/ url, email is required, and that email is saved to BOTH users_user AND account_emailaddress, with a FK back to the ID of the user in users.user.
2. When a user registers using the /auth/users/ POST endpoint, they're saved into users_user only -- but can still (right now) log in via /rest-auth/login/

[lpatmo]

I'm also not opposed to stepping back and exploring magic links... I do like it comparatively in UX (asking users to come up with a unique username and password sometimes feels like adding friction)

[BethanyG]

So -- I am still in the "feeling my way through" part of this process. Once I have a branch functioning, I will push it up for review/experimentation. But for right now:

1. Currently, we have Djangos "traditional" auth -- which is username/pw, email optional. When email is provided, it is saved into the users.user DB table.
2. Currently, we have dango-allauth installed, but it is currently configured for .... nothing. No socialauth backends are present, and email validation is turned off.
3. I will be turning on email validation in my branch and playing with some configurations. I suspect that dango-allauth will be using a FK relation from the users.user table to account.emailaddress table -- and that either through the app or through some FK constraint/DB foo -- email will become required for registration. What I don't yet understand is what change (if any) that will make to users.user, and if that will necessitate a change to the users/models.py file -- which currently only has one customization.
4. All the above is "basic Django" -- I will also need to figure out how this process then works with DRF layered on top of it. That's where django-rest-auth may or may not come into the picture.
5. The JWT stuff is also part of this - so when does someone get that magic token? That part I have no clue about yet.

I'll update this once I figure out what tables and mechanism django-allauth is using to keep track of user account emails.

[BethanyG]

So - I am sure there is an other, nasty shoe to drop. I am by no means done. Currently, I have parallel (3! HA!) paths for obtaining Tokens, registering, and logging in. Clearly, that's 2 too many. But I wanted to err on the side of giving us some time to think about what URLs we wanted for this, and what the app would look like.

The good news? No JWT re-wiring necessary -- this just worked out of the box??? Like WTF?!?. There HAS to be a problem here .. I am just not seeing it yet!

If you pull the django-rest-auth branch from my fork, you can see what is happening with the very rough configuration changes I've made. I recommend starting from no db and building everything, just to be safe.

http://localhost:8000/rest-auth/registration/ will then allow you to "register" -- email there is required. It will immediately hand back a token (which may not be what we want - that's TBD). It is a valid JWT token so 🤷 ....

http://localhost:8000/rest-auth/login/ will allow you to login. Email is NOT required here (yet) -- but we probably want to do that. Another TBD.

But here is the mess:

http://localhost:8000/auth/obtain_token/ also still works, and will serve up a JWT token! LOL -- and all the associated auth URLs are still being routed.

AAAAND http://localhost:8000/auth/users/ still works to create a new user! And will happily create a user and hand back a JWT token. Email here is NOT required. ALL THE THINGS. LOL

[BethanyG]

To get back to the original question:

1. When a user registers using the /rest-auth/registration/ url, email is required, and that email is saved to BOTH users_user AND account_emailaddress, with a FK back to the ID of the user in users.user.
2. When a user registers using the /auth/users/ POST endpoint, they're saved into users_user only -- but can still (right now) log in via /rest-auth/login/
3. Now we get to work out how permissions and JWT token expiration works. And also what this means for extracting info for a user profile.

[BethanyG]

Here is an api endpoints list from the docs

[BethanyG]

And here are the built-in serializers

[BethanyG]

Re: JWT... yeah, from https://django-rest-auth.readthedocs.io/en/latest/installation.html#jwt-support-optional it looks like django-rest-auth only supports djangorestframework-jwt, but I believe we're using a different package.

Forgot to note this above -- we are essentially using djangorestframework-jwt, just a maintained fork of it from Styria-Digital at https://github.com/Styria-Digital/django-rest-framework-jwt. Or at least close enough to appear to "work" 😉

[BethanyG]

So - again - we'll want to maybe think through the flow and the scenarios. My first hot take is that we'll want those register and login endpoints, as well as a validation flow. We may even want to keep the obtain/refresh/delete token ones. But we'll want to put everything under one app/endpoint that's clear -- or at the very least, name our endpoints after what flow they represent. But -- that is further down the line.

[BethanyG]

Adding a clarifying note here about django-rest-auth. The DRF docs suggest switching to dj-rest-auth, since it is being actively maintained. However, it doesn't support django-rest-framework-jwt (our current JWT lib) -- only djanogo-rest-simplejwt. So if we switch, we need to then switch the JWT lib as well. We would also need to update the code in the auth app.

[lpatmo]

Yeah, switching to django-rest-simplejwt sounds likely. I vaguely remember there was a technical reason we chose django-rest-framework-jwt instead of the alternatives, but I've forgotten if the concern still holds... do you remember?

[lpatmo]

Oh nvm, I just read your comment here:

Forgot to note this above -- we are essentially using djangorestframework-jwt, just a maintained fork of it from Styria-Digital at https://github.com/Styria-Digital/django-rest-framework-jwt. Or at least close enough to appear to "work" 😉

What's what we did!

[BethanyG]

UUUUUGH. So. Just ran into an issue with emails not being marked valid when "validated", and was reminded that django-rest-auth is not being maintained. Think we need to switch after all, which necessitates a switch to django-rest-framework-simplejwt, since dj-rest-auth (the maintained lib) only supports django-rest-framework-simplejwt. SIGH I am hopeful that this is largely drop-in code. Wish I hadn't wasted time! Will updates as soon as I get a skeleton working.

[BethanyG]

OK. #187 has been submitted!

This is a django-simpleJWT - django-allauth - dj-rest-auth implementation. Wrote new tests for it, but one intermittently fails. No clue why. Annoying. Also re-wrote the resources tests so they'd pass with the new auth scheme. The tests will probably need to be looked at and re-factored - but I wanted to get this "MVP" up so we can take a look at it.

I struggled a bit with the password-reset emails. Those will need more work - I can file a bug for that. I'll also need to file a few documentation change issues, and one for the "landing page" of the DRF/backend app. I am happy to also implement those - or leave them as "beginner friendly" issues. Either way.

Not sure if we want to also implement Dojser. I can take a look in the am and see if it will be straightforward or not. If it is straightforward, I will do it on another branch, and we can review it as well.

[BethanyG]

Re:Dojser: Looks fairly straightforward to implement, but there are two big caveats.

1. It uses python-social-auth instead of django-allauth. Python-social-auth is designed to be more general and work with other frameworks such as Pyramid and Flask and other ORMs like Mondo and SQLAlchemy. Its newer and has less focused Django support because of it's cross-framework design. There is also less documentation on how to customize and or integrate it. Using dosjer would mean ripping out django-allauth in favor of python-social-auth. Probably not a big deal - but not trivial, given that we've used a cookiecutter template that had django-allauth pre-integrated.

2. It has pre-set api points. They can probably be re-named, but by default they are set to us a users endpoint, not a userauth endpoint, so like the first implementation using dj-rest-auth and django-allauth, all the api points for login etc would change -- but they'd be something like api/v1/users/... etc. All associated tests would also change, but maybe not substatially.

[BethanyG]

This will need some tweaking. Currently, you are able to obtain a token pair from api/v1/auth/token with an unverified email....in fact, the token path bypasses allauth/dj-rest-auth entirely, and is not asking for an email...so we may want to remove it or change it as we move to production, or otherwise keep it as a "non-public" endpoint. We'll want to keep the refresh and the verify for auth purposes..but registration, login, logout and password-reset, et. al. do go through allauth/rest-auth, so those are the endpoints we'll want to mainly use.