RT-147 allauth

[kkowalski-reef]

Intorduces optional integration with django-allauth
(!) new cookiecutter variables:

• use_allauth
• allauth_trust_external_emails
• use_allauth_*

Streamlined config available for providers:

• apple
• atlassian
• discord
• facebook
• github
• gitlab
• google
• microsoft
• openid_connect (any generic OIDC provider)
• twitter

[agoncharov-reef]

I remember allauth has some basic templates which one should always override with custom ones, maybe some custom templates should already be included into cookiecutter? I'm not 100% sure tho.

Also, it allows registration of two types as far as i remember: with sending confirmation email and without it, but here it's not covered at all.

Ideally I would like to have cookiecutter questions be like

• enable registration?
• require email confirmation?
• enable google login?
• enable apple ID login?
• ...

So "adding allauth support" is not about adding it to requirements, INSTALLED_APPS and including instructions in README but about answering few questions and get everything set up for you. With current PR I still have to do stuff manually.

I don't know what original task was so I have no clue whether what I wrote is valid or not, just my thoughts.

[kkowalski-reef]

@agoncharov-reef I agree that this PR doesn't really do much.

It feels to me that in general, I don't really know what settings we would prefer to pull up to the cookiecutter options - lots of allauth things can be simply changed via settings.py - email verification etc.

The templates are project specific and the included one is not pretty but functional. I'd say there is no need to overwrite them in cookiecutter.

Regarding enabling specific providers via cookiecutter options - there are >100 of them. However I see that we probably won't care about most of them ever, so Google / Apple / other popular ones could make sense to be exposed in cookiecutter options - I'll do that.

Enabling/disabling signups - I would see this more as a dynamic setting? Could be a part of the constance config.

[mjurbanski-reef]

require email confirmation?

I cannot really imagine a case in which you allow autoregistration and do not require email confirmation.
It should be either confirmed by SSO (that is an email provider as well (this is important to verify)) or by email directy.

[kkowalski-reef]

I made this PR a bit more opinionated and took the suggestion from @mjurbanski-reef .
To summarize the configuration requirements:

• You get a couple cookiecutter options to enable one (or more) of the most common SSO providers.
• Enabling a provider will set it up so that all you have to do is to acquire client id + client secret and put them into the corresponding env vars

There are a bunch of default settings that will:

• make it so that the email address is used as the username (so you don't have to come up with usernames, just use your email)
• make the email addresses unique
• disable changing of email addresses
• for non-SSO accounts: force you to verify the provided email address when signing up
• trust SSO providers that they verify the ownership of email addresses
• disable the default django auth URLs (/login) and use allauth's login URL as default, so @login_required points you to allauth

I believe this should make it so that you can mostly "just enable allauth" and have a working setup.