What next?
If you want to customize the email templates here are the paths:
templates/account/email/email_confirmation_message.txt
(you can provide an additional .html
file according to the allauth docs but the ACCOUNT_TEMPLATE_EXTENSION
doesn't seem to have an effect here)
templates/registration/password_reset_email.html
Note that it is important to list the app where you include these templates above the other apps in INSTALLED_APPS
. Otherwise Django normally won't use them.
Run the migrations of the new packages.
Go to the admin and create a social app. You just need a client ID and a client secret from GitHub and select the Django site you're using. And remember, we are using the OAuth2 Authorization Code grant type here.
So how does it finally all work together when somebody wants to login via GitHub?
- The SPA
POST
s to /api/auth/social/github/auth-server/
to receive the complete URL to redirect to GitHub's authorization server.
- As the user is now there he enters their GitHub credentials and authorizes our website to receive data from GitHub's resource server.
- The authorization server redirects to our SPA. The SPA takes
code
and state
and POST
s it to /api/auth/social/github/login/
to just login or to create a new account if it doesn't exist or to /api/auth/social/github/connect/
to connect an existing account (user has to be logged in) with the GitHub account.
- Now the backend internally contacts GitHub's authorization server a second time, receives the access token and then contacts GitHub's recource server to get the username, e-mail address, etc.
- The backend creates the user account with that data, generates a token and now responses to the SPA with that token.
Errors? Yes, they will happen. Maybe I'll share how we deal with them another time.
I decided to not use tokens (or JWTs) but just session cookies (even without rest_framework.authtoken
in INSTALLED_APPS
). This can be done with just a few modifications. If you are interested in that I might share that, too.