Project

General

Profile

Bug #14810

comportement sur un artifactresponse vide

Added by Frédéric Péters about 6 years ago. Updated about 4 years ago.

Status:
Fermé
Priority:
Normal
Target version:
Start date:
30 January 2017
Due date:
% Done:

100%

Estimated time:
Patch proposed:
Yes
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.


Files


Related issues

Related to django-mellon - Development #31690: crash sur annulation ssoFermé25 March 2019

Actions

Associated revisions

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

use Jenkinsfile (#14810)

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

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

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).

History

#1

Updated by Benjamin Dauvergne over 5 years ago

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

Updated by Benjamin Dauvergne about 5 years ago

Les tests passent.

#5

Updated by Benjamin Dauvergne about 5 years ago

  • Assignee set to Benjamin Dauvergne
  • Target version set to 1.2.34
#6

Updated by Paul Marillonnet about 5 years ago

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

Updated by Benjamin Dauvergne about 5 years ago

  • Patch proposed changed from Yes to No

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

Updated by Benjamin Dauvergne about 4 years ago

  • Status changed from Nouveau to Solution proposée
  • Patch proposed changed from No to Yes
#10

Updated by Serghei Mihai about 4 years ago

  • Status changed from Solution proposée to Solution validée
#11

Updated by Benjamin Dauvergne about 4 years ago

  • Status changed from Solution validée to Résolu (à déployer)
  • % Done changed from 0 to 100
#12

Updated by Frédéric Péters about 4 years ago

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

Updated by Frédéric Péters about 4 years ago

Also available in: Atom PDF