Bug #7559: MultipleObjectsReturned: get() returned more than one LibertySessionDump -- it returned 2! - Authentic 2 - Redmine Entr’ouvert

Bug #7559

MultipleObjectsReturned: get() returned more than one LibertySessionDump -- it returned 2!

Ajouté par Frédéric Péters il y a presque 9 ans. Mis à jour il y a plus de 6 ans.

Statut:

Fermé

Priorité:

Normal

Assigné à:

Benjamin Dauvergne

Catégorie:

Version cible:

2.2.0

Début:

13 juin 2015

Echéance:

% réalisé:

100%

Temps estimé:

Patch proposed:

Non

Planning:

Description

I am not sure how things happened, multiple concurrent SSO made twice the same object in saml_libertysessiondump. (the concurrent SSO were the result of calls to menu.json of various applications, when building the sidepage menu)

  File "/home/fred/src/eo/authentic/src/authentic2/idp/saml/saml2_endpoints.py", line 526, in sso
    return sso_after_process_request(request, login, nid_format=nid_format)
  File "/home/fred/src/eo/authentic/src/authentic2/idp/saml/saml2_endpoints.py", line 894, in sso_after_process_request
    load_session(request, login)
  File "/home/fred/src/eo/authentic/src/authentic2/saml/common.py", line 286, in load_session
    kind=kind)
...
MultipleObjectsReturned: get() returned more than one LibertySessionDump -- it returned 2!

I wondered if maybe it was because it reused an old session key but the id say otherwise.

authentic_multitenant=> select id from saml_libertysessiondump where django_session_key = 'jqpvw7iayben5i5a50epqk2jvjmhsmp4';
 id 
----
 30
 31

Révisions associées

Révision 8a4830c6 (diff)
Ajouté par Benjamin Dauvergne il y a presque 9 ans

saml: prevent creation of duplicate LibertySessionDump (fixes #7559)

By adding a unicity constraint we prevent .get() of ever raising a
MultipleObjectsReturned exception.

Historique

Mis à jour par Benjamin Dauvergne il y a presque 9 ans

Bug is really difficult, get_or_create() which used to save LibertySessionDump is not safe without a postgresql configured with the serializable isolation level, default level being read commited, as read commited cannot prevent the phantom read problem (the two transactions check if a given row, the two returns none, but in fact after the first transaction commit the second transaction pre-state has changed, there is now a row matching the query but it won't see it, see¹).

Adding an unicity constraint on (django_session_key, kind) could maybe alleviate the biggest problem, that is the load_session() failing. But when two concurrent save will happen one them may fail but I think django has a retry loop inside get_or_create() to prevent the problem in most cases.

.fn1 http://stackoverflow.com/questions/13374335/what-is-the-difference-between-serializable-and-repeatable-read-isolation-level http://www.postgresql.org/docs/9.1/static/transaction-iso.html