Auth0 integration to allow SSO via Github.

[JohnVonNeumann]

So seeing as the product revolves so heavily around Github, it makes sense to only allow Signups via SSO through Github, it ensures better data integrity and a cleaner user experience. The idea here is to use the return JSON supplied by a successful Github auth to populate the User model and supply the relevant information regarding a User's organisations, contributions and other such information that will be used by the other data models such as contribution's and issues. This will obviously all shift and move around as the project grows, which is why I'm going to focus on getting the User generated fully first, before moving to the other models.

I've never coded into the Auth0 or Github API, so I suspect that much like the User model task, this will require some learning, I've estimated accordingly.

[JohnVonNeumann]

I've got a working branch currently that doesn't utilise Auth0, I was having issues implementing it and overall found the docs to be fairly terrible and out of date, I've attempted to communicate with Auth0 via their github issues on their example repo's but doesn't seem like they're interested. Either way, this is technically complete, users can signup/login with Github and the site works fine. It will ultimately just be a case of expanding the permissions required and building user models around the login/signup github data to proper ingest the data.

[JohnVonNeumann]

Sub tasks left to complete for this to be a working feature:

• [ ] Unit tests around new views, templates and any other user generated code.
• [ ] Logout properly implemented.
• [ ] Boilerplate cleaned up to properly reflect this project.

[JohnVonNeumann]

https://auth0.com/blog/building-modern-applications-with-django-and-vuejs/?utm_source=medium&utm_medium=sc&utm_campaign=django_vuejs_apps

This is a cleaner way of implementing what it is I'm after, it separates the Vue section into its own service and enables me to migrate away from ugly django templating, which is what I'm after. This helps create a clean divide.

Ultimately, I feel as though I've completed this task 2-3 times already, but I haven't been happy with the implementations, I'd rather make it clean now than be a pain in the arse later.

[JohnVonNeumann]

Progress has been made on this with #31 and #29

[JohnVonNeumann]

More progress made with #45

Whiteboard session left on trello, previous to wipe off and go again. The overall idea that I've had is that Auth0 probably has a signup function in their AuthService which can be used for a separate auth flow to enable new users to be created in the database, admins can hold a db backup that can be restored to enable development, and the auth0user can be removed from the migrations. https://trello.com/c/n6ZNvM48/45-8th-of-may

[JohnVonNeumann]

https://auth0.github.io/auth0.js/global.html#signup

We can use this to create a separate signup button that will set off a different auth flow.

[JohnVonNeumann]

We could probably use some of Auth0's action/trigger API's to handle post signup flows.

EDIT: They're called Rules and Hooks.

[JohnVonNeumann]

https://kodingnotes.wordpress.com/2018/04/13/auth0-authentication-and-nodejs/

https://github.com/kanesee/ng-node-auth0-kit/tree/master/shared

Examples and tutorial on using Auth0 hooks for creation of records in the backend, this will obviously just have to have some ACL in front of it (from the backend) or token validation to ensure users are being created by the correct principals, naturally, this action won't be common/distributed.

[JohnVonNeumann]

I have got more whiteboards to put up on trello also which shows the list of items required to have this work accepted.

[JohnVonNeumann]

Alright, so I'd probably say that this is effectively done now, as users can use Github via Auth0, the rest of the plumbing hasn't been done, but ultimately, cards have been spun out to show this work.

[JohnVonNeumann]

Apparently I finished this, forgot I did, been a while. closed by #45