The example project should show how to use the package. It could also use DRF's documentation generation to describe the package's endpoints.

Each user should have one primary email address. When they add their first email address it should be marked as the primary one. Deletion of the primary address should not be possible.

Once a user registers, a custom Django signal should be sent out. This will allow other apps to easily perform actions when a user first registers.

When distributed to PyPI, the app does not include its templates, which are required for it to function.

Inside the save method of PasswordResetSerializer class, the below query is being made atm,

So on accessing token.email.user, 2 extra DB roundtrips are made.

This can be optimized using select_related to fetch the related EmailAddress and User objects in the first query only.

Code suggestion:

        token = models.PasswordResetToken.objects.select_related("email__user").get(
            key=self.validated_data["key"]
        )

Since the email confirmation token can expire, we need an endpoint for re-sending the verification email. If an email that has already been verified is sent to this endpoint, no action should be taken.

The registration view doesn't actually use app_settings to get the registration serializer.

We should allow the registration serializer to be customized in the app's settings. To make it easier to provide a custom serializer, we should create a base serializer that can be easily extended.

The registration serializer should support the REQUIRED_FIELDS attribute of the user model. Currently, registration doesn't work if the user model has additional required fields besides a username and password.

The view should use the serializer from #1 to create new users.

The subject of these emails is hard-coded but it would be better to turn them into variables that can be set in the settings.py. For example, I'd like the subject to be: "Welcome to <product_name>! Verify your email address below".

IMHO, it should be changed to django >= 2.2, < 4.0 given the new django release.

Users should be able to use any verified email address to reset their password.

If we truly want to avoid leaking information about the existence of email addresses we need to refactor the EmailAddress model.

The Problem

Consider the case where a user has already registered the email [email protected]. If another user tries to add that email to their account, we must save a duplicate EmailAddress instance so that we can return its id attribute in the response. Without the id, users could determine the existence of other email addresses by simply seeing if the id field is non-null after attempting to add that address.

The Solution

In order to include the id attribute in the response, we have to actually create a new EmailAddress instance and save it. This will require removing the uniqueness constraint from the email field. We will also have to do our own uniqueness checks when registering a new account and adding an email address for a user.

This also introduces the problem of having EmailAddress instances that can never be verified since they are duplicates. We would then need a management command for clearing out these useless instances.

In the metadata for this project in setup.py we have the following:

This suggests that there's no support for Django >= v3.0

However the install_requires:

Specifies any version of Django that's >= v1.10

Which versions are supported?

When a user registers, an email should be sent to the provided address. If the provided address already exists and is verified, the email should be a notification stating that someone attempted to register with that address. If the email isn't in the system or isn't verified, a verification email should be sent to the address.

Probably as a result of running bumpversion, the requirements file for the example project becomes invalid.

The URL template for verifying an email should be customizable. (Either as a Django setting or as a parameter to the registration endpoint)

If a user has a primary email address and then another one is created with EmailAddress.objects.create(...), there end up being two primary email addresses.

When a user registers, the EmailAddress instance that is created should be set as the primary address since the user was just created and cannot have another primary address.

It would be quite good if you could override the permission_class for the new registration and make it open to everyone (rather than using the settings.ini default).

(Great little project, really having fun using it)

The documentation for installing the package shows the old style of URLs. We should show the newer path syntax.

In addition to simply bumping the version of Django, we should switch the example project to the new style of URLs (path vs. url).

The authentication backend is required for users to be able to authenticate using an email address. We can also alias username to email for the backend which will allow users to sign in using Django's built in authentication system (admin, DRF authentication, etc.).

The documentation should be published using Read the Docs.

We should pass the password given in the registration form through Django's default password validation mechanism.

Newer versions of django-email-utils require Django versions greater than or equal to 2.1. This is causing our builds to fail for older Django versions.

Especially with the proposed addition of black in #62, there is a fair amount of setup required to develop the project. This should be documented somewhere.

Our development workflow has changed such that there is no longer a develop branch. Development is instead merged straight to master and tags are used to indicate releases. As such, the installation instructions for the bleeding-edge release should use the master branch.

The Travis CI free-tier has seemingly bitten the dust.

As mentioned in #82.

Since mock was only added to the standard library in 3.3, it's not available for the builds running Python 2.7.

The docs generated by DRF are using the docstring from the generic SerializerSaveView rather than the docstring from the views that extend it.

This would provide a hook for actions that should be performed when an email is performed. To implement this right now you have to add a receiver for the post_save signal and then manually check if the email address is verified.

Trying to run any manage.py command that runs Django's system checks produces the following error:

ERRORS:
<class 'rest_email_auth.admin.PasswordResetTokenAdmin'>: (admin.E108) The value of 'list_display[0]' refers to 'email__user', which is not a callable, an attribute of 'PasswordResetTokenAdmin', or an attribute or method on 'rest_email_auth.PasswordResetToken'.

The serializer should accept a username, email, and password.

The endpoint should take a confirmation token and the user's password. If they match, the email should be verified.

For a formatting consistency we should use a tool such as black to format our codebase.

We need endpoints for listing and editing email addresses.

The ./manage.py check command was added in response to #40, but it really should do its checks in the example project.

Email addresses should be normalized since they are not case sensitive. This also prevents confusion if a user types their email differently sometimes, eg [email protected] and [email protected].

After digging into the RFC for email addresses, only the domain portion of the email is case insensitive.

Another common purpose for normalization is to remove +foo or . from emails attached to providers who deviate from the spec. For example, Gmail ignores . characters, and [email protected] is routed to the same place as [email protected]. However, normalization to this extent is a more specialized problem than this package tries to solve and will not be addressed here.

In some situations the inconvenience of having to provide a password to verify an email address is outweighed by usability concerns. We should accommodate for this situation by providing a setting determining if a password should be required.

Users should not be able to delete the last verified email attached to their account.

The installation instructions should specify that rest_framework needs to be installed rather than restframework.

Right now we just accept whatever password the user provides. It should be run through the same validation as when the user registers.

The .travis.yml config should be set up to automatically deploy tagged builds, but v0.2.0 didn't trigger that for some reason.

Currently, the package refers directly to the hardcoded location of the email templates. If this is replaced with a specified default setting, it would give package users the ability to override the setting and easily use their own email templates.

The command should delete email confirmations that have been expired for a certain amount of time.

The email confirmation model should create a random token that can be used to verify an email address.

An EmailConfirmation instance that is confirmed should be deleted.

Is the following example wanted behavior?
Example:
Registered mail: [email protected]
Request password reset mail: [email protected]

Does not trigger a reset-password mail. Email matching is case sensitive.