Revamp auth: create user profiles and login via email address about gardenhub HOT 9 CLOSED

This goes back to the dilemma I was having before. Do we override the default Django User model, or provide a "Profile" model with a one-to-one relationship with the User model? I'm still conflicted. Both have their set of complications.

from gardenhub.

I'm surprised the default model wouldn't permit this.

from gardenhub.

The default model is intended to be used only for auth. Based on reading the docs I think making a separate model with a relation is the preferred way.

from gardenhub.

Ahh okay

from gardenhub.

Extending Django’s default User

If you’re entirely happy with Django’s User model and you just want to add some additional profile information, you could simply subclass django.contrib.auth.models.AbstractUser and add your custom profile fields, although we’d recommend a separate model as described in the “Model design considerations” note of Specifying a custom user model. AbstractUser provides the full implementation of the default User as an abstract model.

Ref: https://docs.djangoproject.com/en/dev/topics/auth/customizing/#extending-django-s-default-user

Model design considerations

Think carefully before handling information not directly related to authentication in your custom user model.

It may be better to store app-specific user information in a model that has a relation with the user model. That allows each app to specify its own user data requirements without risking conflicts with other apps. On the other hand, queries to retrieve this related information will involve a database join, which may have an effect on performance.

Ref: https://docs.djangoproject.com/en/dev/topics/auth/customizing/#specifying-custom-user-model

Even after reading this, it still doesn't make a lot of sense to me. In what world would two conjoined Django projects be conflicting in a way that we won't need to resolve regardless? Their reasoning is this:

That allows each app to specify its own user data requirements without risking conflicts with other apps.

So, for example, maybe in the future we'll decide to tack on an existing Django project onto GardenHub in order to extend its functionality. That existing codebase may also have an opinion about what the User model should look like, and maybe it even defines its own requirements. Well, if we edit the User model directly, and then that new app also wishes to edit the User model directly, we'll have a problem because they'll conflict. If instead, each project were to define a new model separate from the User model, there would not be such a conflict.

However, who's to say that the "Profile" model from both projects wouldn't each contain a "profile picture" field? If they did, which "Profile" model would you use? Would you have to alter the secondary codebase to pull in the profile picture from your primary codebase? Well, now we're making changes to things anyway, so we didn't really avoid a conflict. Maybe it would at least minimize the effect of a conflict.

I found a good resource showing many different options we could use to handle the situation. I'm still reading through it. https://simpleisbetterthancomplex.com/tutorial/2016/07/22/how-to-extend-django-user-model.html

from gardenhub.

By default, Django uses usernames to authenticate people. If we want to authenticate people against email addresses we'll have to override the User model anyway. It's option 3 in the above link.

You should use a Custom User Model when your application have specific requirements in relation to the authentication process. For example, in some cases it makes more sense to use an email address as your identification token instead of a username.

Still, semantically speaking, it seems that a User is meant to represent auth and nothing else. I'm not sure why, nor am I sure whether we should embrace or ignore that. If we embrace it, option 2 seems like the best idea. Otherwise, piggyback off of option 3 to add more fields.

from gardenhub.

Btw here's an example of a user profile model (option 2): https://stackoverflow.com/a/6092091

from gardenhub.

Okay, I'm certain now we should take this path: https://simpleisbetterthancomplex.com/tutorial/2016/07/22/how-to-extend-django-user-model.html#abstractbaseuser

That is, create a new User class extending AbstractBaseUser, add the relevant fields (and get rid of the "username" in favor of email), then set our new class via AUTH_USER_CLASS in the settings.

The main issue is that we'll need to recreate the database, as this change is not backwards-compatible.

from gardenhub.

Okay, I pushed up some changes that designate auth to a custom user model. This user model contains only an email address for auth (no username) and now we have the ability to add other stuff like a photo, etc. right in models.py.

Only drawback is that we need to trash the dev database now. So @marykatefain you need to do this after you pull

rm db.sqlite3
python manage.py migrate
python manage.py createsuperuser --email "[email protected]"

then go about recreating the dummy data.

Oh, I also upgraded to Django 2.0 so you'll need to run pip install -r requirements.txt again.

from gardenhub.