Projet

Général

Profil

Bug #19149

archimed: tronquer l'uuid reçu à 30 caractères lors de la recherche

Ajouté par Josué Kouka il y a plus de 6 ans. Mis à jour il y a plus de 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Josué Kouka
Catégorie:
-
Version cible:
-
Début:
02 octobre 2017
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

L'username (uuid) passé à l'api de remonté des infos du compte lecteur est de 32 caractères. Or la longueur maximale du username django est de 30 caractères, ce qui génère une erreur 404 lors de la recherche de l'utilisateur.


Fichiers

Révisions associées

Révision 7ea471c3 (diff)
Ajouté par Josué Kouka il y a plus de 6 ans

archimed: truncate sent uuid when over 30 characters (#19149)

Historique

#1

Mis à jour par Josué Kouka il y a plus de 6 ans

#2

Mis à jour par Serghei Mihai il y a plus de 6 ans

Pourquoi dans un if? Il se peut que username soit vide?

La regex (?P<username>[\w+]*) devrait être (?P<username>\w+).

#3

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

Or la longueur maximale du username django est de 30 caractères

Ce n'est pas le bout le plus intéressant de l'histoire. Le bout intéressant qu'il faut documenter sous forme de commentaire au niveau du code c'est que le provisionning assuré par hobo tronque l'uuid à 30 caractères.

J'allais aussi ajouter qu'il ne fallait sans doute pas préfixer le message avec "archimed" pour du code dans mandayejs/views.py mais j'ai malheureusement ouvert ce fichier.

#4

Mis à jour par Josué Kouka il y a plus de 6 ans

Frédéric Péters a écrit :

Or la longueur maximale du username django est de 30 caractères

Ce n'est pas le bout le plus intéressant de l'histoire. Le bout intéressant qu'il faut documenter sous forme de commentaire au niveau du code c'est que le provisionning assuré par hobo tronque l'uuid à 30 caractères.

Hobo n'assure pas de provisionning, les utilisateurs sont créés lors du SSO.

J'allais aussi ajouter qu'il ne fallait sans doute pas préfixer le message avec "archimed" pour du code dans mandayejs/views.py mais j'ai malheureusement ouvert ce fichier.

Je vais faire un ticket pour restructurer cette partie du code.

Dans ce patch, troncature au niveau de l'url.

#5

Mis à jour par Josué Kouka il y a plus de 6 ans

Grosse bourde, dans ce patch. J'en refais un autre.

#6

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

Hobo n'assure pas de provisionning, les utilisateurs sont créés lors du SSO.

Uh uh uh ? D'une part ça serait un bug, il doit y avoir un agent hobo pour le provisionning des usagers. D'autre part la coupure à 30 caractères reste le fait d'un composant externe (si c'est le SSO, c'est mellon), et ça doit être noté dans un commentaire plutôt qu'avoir un [:30] qui vient sans explication.

#7

Mis à jour par Josué Kouka il y a plus de 6 ans

Frédéric Péters a écrit :

D'autre part la coupure à 30 caractères reste le fait d'un composant externe (si c'est le SSO, c'est mellon), et ça doit être noté dans un commentaire plutôt qu'avoir un [:30] qui vient sans explication.

Ok, j'y ai ajouté des commentaires et modifier les tests.

#8

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

Et l'absence de provisionning par Hobo, une réaction ?

#9

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

        # mellon truncates username to 30 characters
        # thus the passed username should be truncated to 30 characters
        # for searching purposer

Se relire et corriger.

            user = User.objects.get(username=username)
            # *startswith* to deal with the looseness of sqlite
            # and the strictness of postgres
            user = User.objects.get(username__startswith=username)

Uh uh uh non; ça ne va pas de dire "pas la moindre idée de ce qu'il y a dans la base, tapons dedans"; que ça soit sqlite ou postgresql la même info doit être stockée dedans.

#10

Mis à jour par Josué Kouka il y a plus de 6 ans

Uh uh uh ? D'une part ça serait un bug, il doit y avoir un agent hobo pour le provisionning des usagers

Je me trompe peut etre, mais je ne vois pas trop l'interet du provisionning hobo pour mandayejs. Est ce qu'il y'a un interet a avoir des utilisateurs dans mandayejs sans que ceux ci ne soient liés ? Je vois plutot MandayeJS comme Passerelle, ou les seuls utilisateurs qui y sont créés sont ceux qui s'y sont déja connecté.

#11

Mis à jour par Josué Kouka il y a plus de 6 ans

Frédéric Péters a écrit :

[...]

Se relire et corriger.

Ok, merci. C'est fait.

[...]

Uh uh uh non; ça ne va pas de dire "pas la moindre idée de ce qu'il y a dans la base, tapons dedans"; que ça soit sqlite ou postgresql la même info doit être stockée dedans.

Corrigé.

#12

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

comme Passerelle, ou les seuls utilisateurs qui y sont créés sont ceux qui s'y sont déja connecté

Uh uh uh. Notre système de provisionning doit fonctionner sur tous nos modules, si tu vois que ce n'est pas le cas pour Passerelle, il faut soulever un bug.

#13

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

Se relire et corriger.

Ok, merci. C'est fait.

Mais le patch que tu attaches à nouveau, c'est l'autre ? (et pourquoi deux patchs, d'ailleurs)

#14

Mis à jour par Josué Kouka il y a plus de 6 ans

Frédéric Péters a écrit :

Se relire et corriger.

Ok, merci. C'est fait.

Mais le patch que tu attaches à nouveau, c'est l'autre ? (et pourquoi deux patchs, d'ailleurs)

Désolé, voici le bon

#15

Mis à jour par Serghei Mihai il y a plus de 6 ans

Il y a des virgules dans le name_id transmis?

#16

Mis à jour par Thomas Noël il y a plus de 6 ans

En fait le [\w,-] est une erreur qu'on retrouve souvent dans passerelle, et qui a commencé à se répandre dans combo (une fois dans calendar/urls.py). A ne pas trop répéter :)

#17

Mis à jour par Josué Kouka il y a plus de 6 ans

Ok, correction apporté dans ce patch.

#18

Mis à jour par Serghei Mihai il y a plus de 6 ans

Ack

#19

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

Dans #17196 on découvre des uuid qui contiennent d'autres caractères.

#20

Mis à jour par Josué Kouka il y a plus de 6 ans

  • Statut changé de En cours à Résolu (à déployer)
#21

Mis à jour par Frédéric Péters il y a plus de 5 ans

  • Statut changé de Résolu (à déployer) à Fermé

Formats disponibles : Atom PDF