It gets indexed when the live site has been deployed, but the login requirement hasn't been lifted yet. After the go-live it remains in google index as one of the most important pages since google thinks that it used to be the "homepage".

On the login screen the staff users are shown along with superuser. One can login with a simple stuff user and observe that eg half of the applications and plugins aren't visible.

I debugged that issue few times already, thinking that it's related to the loading of INSTALLED_APPS.

Would be great to either hide staff users, or mark them respectively.

• django v4 compatibility: aldryn_sso/views.py", line 6, ImportError: cannot import name 'is_safe_url' from 'django.utils.http'
• django 4 removed is_safe_url

I tested with Aldryn SSO 1.1.16 with the following settings:

ALDRYN_SSO_OVERIDE_ADMIN_LOGIN_VIEW = False
ALDRYN_SSO_ALWAYS_REQUIRE_LOGIN = 'basicauth'
ALDRYN_SSO_BASICAUTH_USER = 'user'
ALDRYN_SSO_BASICAUTH_PASSWORD = 'pass'

it seems like it may be fixed by rendering the response in there by calling render() on TemplateResponse.

https://github.com/aldryn/aldryn-sso/blob/01105801fa6ee7c6f7d3491d7bc10ab7e8e1c89d/aldryn_sso/middleware.py#L138-L147

Error

Environment:


Request Method: GET
Request URL: https://xxxxxxxxxxxx-stage.us.aldryn.io/admin

Django Version: 1.11.10
Python Version: 3.6.3
Installed Applications:
['aldryn_addons',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.messages',
 'aldryn_sso',
 'django.contrib.admin',
 'django.contrib.staticfiles',
 'aldryn_django',
 'aldryn_sites',
 'raven.contrib.django',
 'wagtail.wagtailforms',
 'wagtail.wagtailredirects',
 'wagtail.wagtailembeds',
 'wagtail.wagtailsites',
 'wagtail.wagtailusers',
 'wagtail.wagtailsnippets',
 'wagtail.wagtaildocs',
 'wagtail.wagtailimages',
 'wagtail.wagtailsearch',
 'wagtail.wagtailadmin',
 'wagtail.wagtailcore',
 'modelcluster',
 'taggit',
 'xxxxxxxxxxxx.authentication',
 'xxxxxxxxxxxx.blockpages',
 'xxxxxxxxxxxx.categories',
 'xxxxxxxxxxxx.content',
 'xxxxxxxxxxxx.esi',
 'xxxxxxxxxxxx.documents',
 'xxxxxxxxxxxx.forms',
 'xxxxxxxxxxxx.home',
 'xxxxxxxxxxxx.images',
 'xxxxxxxxxxxx.navigation',
 'xxxxxxxxxxxx.search',
 'xxxxxxxxxxxx.units',
 'xxxxxxxxxxxx.utils',
 'xxxxxxxxxxxx.years',
 'wagtail.contrib.modeladmin',
 'wagtail.contrib.settings',
 'wagtail.contrib.wagtailsearchpromotions',
 'captcha',
 'wagtailcaptcha']
Installed Middleware:
['raven.contrib.django.middleware.DjangoRestFrameworkCompatMiddleware',
 'raven.contrib.django.middleware.SentryMiddleware',
 'django.middleware.gzip.GZipMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'aldryn_sso.middleware.BasicAuthAccessControlMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'aldryn_django.middleware.LanguagePrefixFallbackMiddleware',
 'django.middleware.locale.LocaleMiddleware',
 'django.contrib.sites.middleware.CurrentSiteMiddleware',
 'aldryn_sites.middleware.SiteMiddleware',
 'django.middleware.security.SecurityMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 'wagtail.wagtailcore.middleware.SiteMiddleware',
 'wagtail.wagtailredirects.middleware.RedirectMiddleware']



Traceback:

File "/virtualenv/lib/python3.6/site-packages/django/core/handlers/base.py" in get_response
  131.                 response = middleware_method(request, response)

File "/virtualenv/lib/python3.6/site-packages/django/middleware/common.py" in process_response
  139.             response['Content-Length'] = str(len(response.content))

File "/virtualenv/lib/python3.6/site-packages/django/template/response.py" in content
  129.                 'The response content must be rendered before it can be accessed.'

Exception Type: ContentNotRenderedError at /admin
Exception Value: The response content must be rendered before it can be accessed.

Failing in - https://github.com/django/django/blob/01448a97e075df08ed0f89c443ee35e649dfb630/django/template/response.py#L127-L131

• aldryn-sso removes the password from a local user upon SSO login
• the user can thereafter not log in anymore without SSO. There are a couple of use cases where this is necessary, for example when a separate frontend relies on username/passwort authentication only and Divio admin users should still be able to log in there for testing purposes.

the current cache headers on the initial response during a login request are not correctly set which could result in cached authentitakion tokens provided to the authentication server

aldryn-sso doesn't work for me with custom user models. I think the OneToOneField here: https://github.com/aldryn/aldryn-sso/blob/f81ddaf9f40189195e40f01c7f6bec72890cfda4/aldryn_sso/models.py#L21 should point to settings.AUTH_USER_MODEL rather than django.contrib.auth.models.User.

Is there a reason why it points to the vanilla user or should I create a Pull Request for this?

• we fixed this as follows:

add this to your settings.py, and remove any other occurence of aldryn-sso configuration, especially the middleware (aldryn_sso.middleware.AccessControlMiddleware).

################################################################################
# ALDRYN-SSO ADDON IS NOT WORKING PROPERLY BY DEFAULT, SO WE HAVE TO
# MANUALLY ENABLE THE aldryn_sso MIDDLEWARE IF REQUIRED
################################################################################
ALDRYN_SSO_LOGIN_WHITE_LIST = []

ALDRYN_SSO_ALWAYS_REQUIRE_LOGIN = boolean_ish(
    env(
        'ALDRYN_SSO_ALWAYS_REQUIRE_LOGIN',
        default=env('STAGE') == 'test',
    )
)

if ALDRYN_SSO_ALWAYS_REQUIRE_LOGIN:
    ALDRYN_SSO_LOGIN_WHITE_LIST = [
        reverse_lazy('simple-sso-login'),
        reverse_lazy('aldryn_sso_login'),
        reverse_lazy('aldryn_sso_localdev_login'),
        reverse_lazy('aldryn_localdev_create_user'),
    ]
    position = MIDDLEWARE.index('django.contrib.auth.middleware.AuthenticationMiddleware') + 1
    MIDDLEWARE.insert(position, 'aldryn_sso.middleware.AccessControlMiddleware')
    SHARING_VIEW_ONLY_TOKEN_KEY_NAME = env('SHARING_VIEW_ONLY_TOKEN_KEY_NAME')
    SHARING_VIEW_ONLY_SECRET_TOKEN = env('SHARING_VIEW_ONLY_SECRET_TOKEN')
################################################################################

Also, we recommend to remove aldryn configuration completely from your projects and use aldryn-sso standalone as per the example in djangocms-template project: https://github.com/django-cms/djangocms-template/blob/master/backend/settings.py#L619-679

Basically after a data copy/restoration though divio control panel, or a divio project push db run, if you already had a user in the admin panel the following error is raised:

IntegrityError at /aldryn_sso/login/authenticate/
duplicate key value violates unique constraint "backend_auth_user_email_key"
DETAIL:  Key (email)=([email protected]) already exists.

It's possible to workaround by renaming changing the original's user email to something as [email protected], but of course that's hardly a satisfactory solution.

currently it shows the admin login form. But actually it should show a message that the user is not staff and a logout link.

how to reproduce:

• create a user manually in django admin
• create a divio user with the samlemail adress on divio.com
• try to log in with SSO on your project
• 500 server error : IntegrityError
  duplicate key value violates unique constraint "backend_auth_user_email_key"

Make sure aldryn sso is not adding caching when loading it's login view.

Internal: 22602993277

It looks like user_data didn't contain an email:

It was equal to:

user_data =  {first_name: 'Anastasiia', is_active: True, is_staff: True, is_superuser: True, last_name: 'Kuvshinova'}

Hence email=user_data.pop('email') raises an error. I wonder whether it can be divio sso issue?

That's related to #67

If SSO is enabled, do an ajax request to control.aldryn.com to check whether I'm already logged in there. If yes, do the redirect loop automatically.

currently our login page is at /login/. This is likely to clash with other peoples login pages. Put it at a better location.