Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Django-allauth integration #108

Open
wants to merge 12 commits into
base: main
Choose a base branch
from
Open

Conversation

mojeto
Copy link
Contributor

@mojeto mojeto commented Jan 29, 2018

  • Enables social account Sign Up and login.
    • Only Google for now.
  • Google social provider has to be configured manually in django admin after deploy.
  • It works with Wagtail for single site configuration (one site in django sites and one site in wagtail site)
  • I haven't tested it for multi site configuration.
  • Requires Enable SSL #68 to be fixed.
  • Sign In by standard credentials is allowed.
  • Adds an option to Sign Up (by Google or standard credentials).

Ref #70

@mojeto mojeto self-assigned this Jan 29, 2018
@@ -190,7 +202,7 @@

# Wagtail settings

LOGIN_URL = 'wagtailadmin_login'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is is defined now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All login pages points to django-allauth login page.
Wagtail admin login page is redirect in urls.py

LOGIN_URL defined in base.py on line 205 now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah sorry, I missed the double assignment WAGTAIL_FRONTEND_LOGIN_URL = LOGIN_URL = ...

- [x] `'allauth.socialaccount.providers.google'` in `INSTALLED_APPS`

### Configuration in Google developer console
- [ ] [Create a new project](https://console.developers.google.com/projectcreate)
Copy link
Contributor

@loicteixeira loicteixeira Jan 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe some of those steps to be done already?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created a testing project to run it and test it locally. A new project (owned by somebody else than me) should be created for the live site.

Copy link
Contributor

@loicteixeira loicteixeira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving for the back-end work but as discussed offline, it will need some styling before merging.

@mojeto mojeto force-pushed the feature/django-allauth-integration branch from d4f170d to 84155b3 Compare January 31, 2018 01:22
@loicteixeira
Copy link
Contributor

@mojeto I found out today that there is a WAGTAIL_PASSWORD_MANAGEMENT_ENABLED setting which should be disabled when authentication is handled by a third party. However I'm not sure how this applies here as if I remember correctly, we do both.

@mojeto
Copy link
Contributor Author

mojeto commented Feb 27, 2018

Good spotting @loicteixeira . We allow user password authentication in allauth. So keeping WAGTAIL_PASSWORD_MANAGEMENT_ENABLED means we may set user password in admin - good to keep that option. I would think more about WAGTAIL_PASSWORD_RESET_ENABLED to be set to False otherwise we have two different pages to reset user password.

@mojeto mojeto force-pushed the feature/django-allauth-integration branch from 84155b3 to 79c3263 Compare March 7, 2018 01:42
@janzenz janzenz self-assigned this Sep 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants