Projet

Général

Profil

Bug #14810

comportement sur un artifactresponse vide

Ajouté par Frédéric Péters il y a environ 7 ans. Mis à jour il y a environ 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
Début:
30 janvier 2017
Echéance:
% réalisé:

100%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Sur un problème de signature de clé, on se trouve avec authentic qui va genre répondre <samlp:ArtifactResponse><samlp:Status><samlp:StatusCode Value="...Success"/></samlp:Status></samlp:ArtifactResponse>, sans <samlp:Response>.

If the issuer of an artifact receives a <samlp: ArtifactResolve> message that it can understand, it MUST return a <samlp: ArtifactResponse> with a <samlp:StatusCode> value of urn:oasis:names:tc:SAML:2.0:status: Success , even if it does not return the corresponding messa ge (for example because the artifact requester is not authorized to receive the me ssage or the artifact is no longer valid).

Ça me semble donc ok côté spec, mais django-mellon a comme comportement d'alors retenter le login, ce qui va rééchouer de pareille manière, et donc série sans fin de redirections.


Fichiers


Demandes liées

Lié à django-mellon - Development #31690: crash sur annulation ssoFermé25 mars 2019

Actions

Révisions associées

Révision 91f726ed (diff)
Ajouté par Benjamin Dauvergne il y a environ 5 ans

use Jenkinsfile (#14810)

- Copied from authentic2-auth-kerberos
- Removal of .coveragerc as it prevented coverage from working, dunno
why.

Révision f2e05b84 (diff)
Ajouté par Benjamin Dauvergne il y a environ 5 ans

prevent redirection loop on artifact resolution errors (fixes #14810)

Signature of method sso_failure() is changed to match the name name of
the context variable in template mellon/authentication_failed.html
(idp_message => reason).

Historique

#1

Mis à jour par Benjamin Dauvergne il y a plus de 6 ans

Je pense que sur une erreur de signature l'IdP devrait retourner une erreur qui indique le problème, néanmoins ton analyse est bonne on ne devrait pas boucler sans raison, en tout cas pas plus d'une fois.

#4

Mis à jour par Benjamin Dauvergne il y a environ 6 ans

Les tests passent.

#5

Mis à jour par Benjamin Dauvergne il y a environ 6 ans

  • Assigné à mis à Benjamin Dauvergne
  • Version cible mis à 1.2.34
#6

Mis à jour par Paul Marillonnet il y a environ 6 ans

Je ne comprends pas en quoi tu as besoin de modifier la signature de la méthode sso_failure (d'ailleurs il reste un paramètre login qui traîne lorsqu'on l'appelle à la dernière ligne de LoginView.continue_sso_artifact).

#7

Mis à jour par Benjamin Dauvergne il y a environ 6 ans

  • Patch proposed changé de Oui à Non

Paul Marillonnet a écrit :

Je ne comprends pas en quoi tu as besoin de modifier la signature de la méthode sso_failure (d'ailleurs il reste un paramètre login qui traîne lorsqu'on l'appelle à la dernière ligne de LoginView.continue_sso_artifact).

  • au lieu de threader (ça veut dire passer un argument d'appels en appels) j'utilise le fait qu'il est déjà stocké dans self.profile c'est plus lisible
  • je renomme idp_message par reason parce que la raison ne vient pas toujours de l'IdP et donc c'est plus clair ainsi
  • je donne une valeur par défaut à status_codes parce que j'imagine que je n'en aurai pas toujours (par contre () au lieu de None je ne sais pas trop)

Effectivement il y a un login qui traîne je vais voir si les tests le chope et sinon voir pourquoi. Merci.

#8

Mis à jour par Benjamin Dauvergne il y a environ 5 ans

  • Statut changé de Nouveau à Solution proposée
  • Patch proposed changé de Non à Oui
#10

Mis à jour par Serghei Mihai il y a environ 5 ans

  • Statut changé de Solution proposée à Solution validée
#11

Mis à jour par Benjamin Dauvergne il y a environ 5 ans

  • Statut changé de Solution validée à Résolu (à déployer)
  • % réalisé changé de 0 à 100
#12

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

  • Statut changé de Résolu (à déployer) à Solution déployée
#13

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

Formats disponibles : Atom PDF