Project

General

Profile

Bug #7150

Get authentic2 working with Django 1.8

Added by Nickolas Grigoriadis over 4 years ago. Updated over 1 year ago.

Status:
Fermé
Priority:
Normal
Category:
-
Target version:
Start date:
05 May 2015
Due date:
% Done:

100%

Patch proposed:
Yes
Planning:
No

Description

Since Django 1.8 is a long-term-support release, with a promise of security updates for 2 years, and this being a very security concious application, it seems prudent to support 1.8 as soon as able.

On a quick glance, custom_user and sekizai seems to be pain points.

0001-custom_user-fix-initial-migration.patch View (1.1 KB) Benjamin Dauvergne, 14 May 2015 11:00 PM

Associated revisions

Revision 6b1977f2 (diff)
Added by Benjamin Dauvergne over 4 years ago

custom_user: fix initial migration

fixes #7150

Revision 43270b86 (diff)
Added by Benjamin Dauvergne over 4 years ago

auth_migrations: prevent collision with related names

Groups and permissions field had the same related names on auth.User and
custom_user.User.

fixes #7150

Revision cc99b61a (diff)
Added by Benjamin Dauvergne over 4 years ago

tox.ini: prepare environment for testing on Django 1.8 (#7150)

Revision a753ba25 (diff)
Added by Benjamin Dauvergne about 4 years ago

setup.py: raise requirement on django-tables to >1.0 for Django 1.7 and 1.8 support (#7150)

Revision a8ee65d8 (diff)
Added by Benjamin Dauvergne about 4 years ago

Django 1.8 compatibility (fixes #7150)

Revision 293ff36b (diff)
Added by Benjamin Dauvergne about 4 years ago

Django 1.8 compatibility (again, fixes #7150)

Revision eda129d7 (diff)
Added by Benjamin Dauvergne about 4 years ago

custom_user: add missing migration (fixes #7150)

Revision c481e99a (diff)
Added by Benjamin Dauvergne over 3 years ago

copy AbstractUser from django.contrib.auth for Django 1.8 compatibility (#7150)

AbstractUser.last_login was modified between Django 1.7 and 1.8. To stay
compatible with both, we have to copy AbstractUser into authentic2. In the
future we should follow evolution of user models on Django side or move back to
the shared AbstractUser model if we ever dump compatibility with Django 1.7.

Revision 74e7446e (diff)
Added by Benjamin Dauvergne over 3 years ago

override pre-Django 1.8 PasswordResetTokenGenerator (#7150)

It supposes that user.last_login is always a datetime, which is not true anymore.

Revision dd5a6289 (diff)
Added by Benjamin Dauvergne over 3 years ago

completely remove transient user support (#7150)

Transient LDAP user has never really worked, and transient SAML user do not
exist anymore since remove of authsaml2. Since Django 1.8 transient user are not
compatible with django.contrib.auth anymore as it enforces that the stored
_auth_user_id is a real model primary key.

Revision 573f2bb0 (diff)
Added by Benjamin Dauvergne over 3 years ago

ldap: factorize keep_password initialization (#7150)

Revision 756cac56 (diff)
Added by Benjamin Dauvergne over 3 years ago

ldap: directly call LDAPUser.keep_password in return_django_user (#7150)

Revision 2daf8908 (diff)
Added by Benjamin Dauvergne over 3 years ago

store LDAP data in session instead of replacing LDAPUser.pk by a pickle object (#7150)

Django > 1.8 does not allow anymore to store anything in the _auth_user_id
key in the session as it checks it can be converted to an user model pk.

History

#1 Updated by Benjamin Dauvergne over 4 years ago

For sekizai we have to wait for their release, what is the pain point with custom user exactly ?

#2 Updated by Benjamin Dauvergne over 4 years ago

  • Status changed from Nouveau to Information nécessaire

Currently all our unit tests (including login, registration and SAML tests) run under Django 1.8 (but none of them need django-sekizai I think), I change status to more informations needed.

#3 Updated by Benjamin Dauvergne over 4 years ago

  • Target version set to 2.2.0

#4 Updated by Nickolas Grigoriadis over 4 years ago

When I did a quick test on Django1.8, the custom_user migrations failed.

Also, what is sekizai used for? I know it crops up as a pain point far too often for my liking.

#5 Updated by Benjamin Dauvergne over 4 years ago

Try again and report the traceback on the custom user migration. Thanks. Sekizai is used to include static files from templates which are rendered before the rendering of the final template. It's the same use case as in django-cms for example. Please to propose patches with another solution to this problem if you want a change on this point.

#6 Updated by Nickolas Grigoriadis over 4 years ago

The custom_user traceback:

Applying custom_user.0001_initial...Traceback (most recent call last):
File "./authentic2-ctl", line 20, in <module>
execute_from_command_line(sys.argv[:1] + argv)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/core/management/commands/test.py", line 30, in run_from_argv
super(Command, self).run_from_argv(argv)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/core/management/base.py", line 390, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/core/management/commands/test.py", line 74, in execute
super(Command, self).execute(*args, **options)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/core/management/base.py", line 441, in execute
output = self.handle(*args, **options)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/core/management/commands/test.py", line 90, in handle
failures = test_runner.run_tests(test_labels)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/test/runner.py", line 210, in run_tests
old_config = self.setup_databases()
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/test/runner.py", line 166, in setup_databases
**kwargs
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/test/runner.py", line 370, in setup_databases
serialize=connection.settings_dict.get("TEST", {}).get("SERIALIZE", True),
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/backends/base/creation.py", line 368, in create_test_db
test_flush=not keepdb,
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/core/management/__init__.py", line 120, in call_command
return command.execute(*args, **defaults)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/core/management/base.py", line 441, in execute
output = self.handle(*args, **options)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 221, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/migrations/executor.py", line 110, in migrate
self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/migrations/executor.py", line 147, in apply_migration
state = migration.apply(state, schema_editor)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/migrations/migration.py", line 115, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/migrations/operations/special.py", line 183, in database_forwards
self.code(from_state.apps, schema_editor)
File "/home/grigi/work/a2/src/authentic2/custom_user/migrations/0001_initial.py", line 20, in copy_old_users_to_custom_user_model
for old_user in old_users:
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/models/query.py", line 162, in iter
self._fetch_all()
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/models/query.py", line 965, in _fetch_all
self._result_cache = list(self.iterator())
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/models/query.py", line 238, in iterator
results = compiler.execute_sql()
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 826, in execute_sql
sql, params = self.as_sql()
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 375, in as_sql
extra_select, order_by, group_by = self.pre_sql_setup()
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 48, in pre_sql_setup
self.setup_query()
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 39, in setup_query
self.select, self.klass_info, self.annotation_col_map = self.get_select()
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 203, in get_select
related_klass_infos = self.get_related_selections(select)
File "/home/grigi/work/a2/.pyenv/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 751, in get_related_selections
', '.join(_get_field_choices()) or '(none)',
django.core.exceptions.FieldError: Invalid field name(s) given in select_related: 'user_permissions', 'groups'. Choices are: (none)

Seems the issue is somewhere in "copy_old_users_to_custom_user_model". When I disable calling that function it passes.

#7 Updated by Benjamin Dauvergne over 4 years ago

#8 Updated by Benjamin Dauvergne over 4 years ago

  • Assignee set to Benjamin Dauvergne

#9 Updated by Benjamin Dauvergne over 4 years ago

  • % Done changed from 0 to 100
  • Status changed from Nouveau to Résolu (à déployer)

#14 Updated by Benjamin Dauvergne over 3 years ago

  • Status changed from Résolu (à déployer) to Solution déployée

#15 Updated by Benjamin Dauvergne over 1 year ago

  • Status changed from Solution déployée to Fermé

Also available in: Atom PDF