Github/Gitlab social auth

[EDsCODE]

Addresses #404

Implemented: When the SOCIAL_AUTH_GITLAB_KEY (or SOCIAL_AUTH_GITHUB_KEY)and SOCIAL_AUTH_GITLAB_SECRET (or SOCIAL_AUTH_GITHUB_SECRET) are provided as env variables wherever your instance is deployed, social auth with that platform will be available. The auth is implemented using python-social-auth as suggested. Currently, github and gitlab auth have been implemented.

Note: The redirect_uri that github or gitlab asks for should be in the form http://{domain_name}/complete/{gitlab or github}/

What's left:

• style the buttons as they're quite barebones right now
• tests?
• possible edge case where the social auth doesn't return email at all will break login

[timgl]

This is awesome! Thank you so much for doing this. It looks good, will do a proper QA tomorrow.

I like the bare-bones styling of the buttons, it would be good if they aligned with the button above on the left and right

[timgl]

There's a couple of things missing:

• There's a bit of logic around what happens after a user account is created when a user signs up to a team that needs to be put into the social auth pipeline.
• I think we can safely associate users by email (if they signed up using their email before)

[EDsCODE]

There's a couple of things missing:

• There's a bit of logic around what happens after a user account is created when a user signs up to a team that needs to be put into the social auth pipeline.
• I think we can safely associate users by email (if they signed up using their email before)

Agreed! In fact, I was reviewing the implementation and realized I wasn't being thorough with the access points because I'm guessing these sign in options should be available on the initial admin sign up where a new team is created right? Going to add a custom pipeline to distinguish these signup/login paths.

[timgl]

I'm actually less concerned about the admin setup page, as I don't think anyone will have set up GitHub keys before setting up the master account, plus we still need to get the other fields (company name, full name etc) that we can't get easily from github/gitlab.

[EDsCODE]

hmm this will be a blocker for the standard login.html page too because if a new user trying to join a team ends up trying to auth from the default login page, social auth will complete but land them on a blank page as they're not associated with a team. There's two routes I can take with this PR:

1. (slightly lengthier) I can setup a unique flow where the admin setup and regular login page both have social auth capabilities. If a new user is joining (no team association), we can use a partial pipeline to redirect the user to a form where the user can enter a team token or create a new team.
2. (condensed) I can leave the social auth as it is now and just finish including the team addition in the pipeline as noted above. If a user who isn't associated with a team attempts to login from the normal page, they can be redirected to an error page noting that they're unable to login due to not belonging to a team.

I'd suggest 1 but 2 keeps this PR contained a bit better!

[timgl]

Good find! I much prefer 2 anyway as that feels right (who would know a team code of the top of their head?). We should make sure no user gets created, which I think you should be able to do by putting the function at the right point in the pipeline.

👍

[EDsCODE]

uprooted and used our own custom create user

[timgl]

QA'd, functionally works beautifully. Just two small things and then we're good to go 👍