Produits Entr'ouvert » Combo

C'est Fargo, comme bijoe, qui se planterait de clé de signature.

entrouvert.com-access.log:5.135.221.12 - - [10/Jun/2018:12:08:07 +0200] "GET /api/documents/recently-added?NameID=b5df639331494bffa80da900994f1c3b&orig=portail-citoyen-publik.entrouvert.com&algo=sha256&timestamp=2018-06-10T10%3A08%3A07Z&nonce=de1ab17c87fd791083356f505e6427c9L&signature=SMu0fbfDSJnmL7W90hQqto4fVG6wpNuBi/Xn1HDxQLc%3D HTTP/1.1" 301 5 "-" "python-requests/2.11.1" 

"Fun", j'ai trouvé le bug.

En descendant beaucoup, hobo, django rest framework, django, en posant pas mal de print de debug, en faisant ça sur la prod pour avoir une bonne dose de l'aléatoire d'une réelle utilisation (pas bien, mais sans ça je n'y serais pas arrivé), ce qui se passe c'est que le code de la vue fargo n'est jamais appelé (ok d'accord), mais le code de nos classes d'authentification rest framework de hobo non plus (et donc l'hypothèse de signature invalide, à l'eau), et en fait le code de django rest framework en lui-même, jamais appelé non plus.

Il se fait que par moment, le code de la vue n'est pas appelé, parce qu'un middleware intervient.

Ce middleware, c'est PassiveAuthenticationMiddleware, de django-mellon, qui décide d'intercepter la vue pour tenter une redirection. Qui décide ça parce qu'un cookie (settings..OPENED_SESSION_COOKIE_NAME) est présent.

Ce cookie, il est présent parce que combo.utils.requests, c'est un RequestSession, qui persiste les cookies, et qu'il y a eu, lors du traitement d'une requête passée, un appel qui aura enregistré ce cookie; dans mon idée ça pouvait arriver via une redirection mais en fait, ça vient d'un appel direct à l'API d'Authentic, genre https://connexion-publik.entrouvert.com/api/users/(whatever).

Solution cheap, cookies.clear() systématique.

commit cd8eca8627718d8c35eb46f18c27a875adc2c89b
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Sun Jun 10 14:31:32 2018 +0200

    fargo: add required trailing slash to recent-documents API endpoint (#24406)