Journal Message d'intérêt public - reconfiguration nécessaire aux clients pour poster sur la tribune

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes : aucune
15
26
juin
2018

Mes chères amies et chers amis mytilidés bonjour,

Vous avez peut-être remarqué avec effroi que depuis ce funeste dimanche, votre client de tribune (communément appelé un "coincoin", pour les initiés) ne vous permet plus de poster sur la tribune de LinuxFR.org (qu'il est par ailleurs dorénavant possible d'afficher dans la sidebar du site, à partir de vos préférences pour pouvoir discuter tout en visitant LinuxFR).

Il se trouve donc que depuis cet incident et la mise en production inopinée qui en a découlé, un cookie supplémentaire est nécessaire à la bonne authentification de ces clients.

Jusqu'ici, il était seulement nécessaire de renseigner le cookie linuxfr.org_session.

À présent, un second cookie remember_account_token est aussi nécessaire, à retrouver lui aussi dans les informations de votre navigateur. Attention, il doit provenir de la même session que le cookie linuxfr.org_session. Contrairement à ce qu'on a pu redouter au départ, il n'est pas nécessaire de renseigner la donnée de POST authenticity_token.

Il est trop tôt savoir exactement ce qu'il en est, mais il est possible que le cookie remember_account_token ait une durée de vie plus courte que le précédent, ce qui signifierait qu'il est nécessaire de le remettre à jour peut-être toutes les semaines par exemple. Pour l'instant, le problème ne s'est pas encore posé.

  • # Rollback?

    Posté par  (site Web personnel) . Évalué à 1.

    Si j'ai bien compris, la mep dimanche a causé plusieurs problèmes toujours non résolus. Le mieux n'est-il pas de faire un retour arrière?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Ce "funeste dimanche" est tout de même une progression sur au moins un point

    Posté par  (site Web personnel) . Évalué à 6.

    Tout d'abord, je vous remercie de la promptitude que vous avez eu de remettre en ligne le site Internet, sans défaillance si "majeure" que ça pour le commun des lecteurs, surtout après une défaillance électrique.
    Je suis très heureux qu'il y ait enfin une redirection de http://linuxfr.org vers https://linuxfr.org. Plus qu'à régler les quelques soucis qui trainent et passer en IPv6 :-)

    Merci du travail conséquent fourni

  • # Session invalidée ?

    Posté par  (site Web personnel) . Évalué à 5. Dernière modification le 26/06/18 à 18:45.

    Au sujet des attaques dites CSRF (Cross Site Request Forgery), il y a 2 moyens de s'en prémunir :

    • un jeton anti-CSRF dans les formulaires
    • vérifier l'entête HTTP Origin (quand il est disponible).

    Rails fournit depuis très longtemps la première solution et un hack avait été mis en place pour aussi avoir la deuxième solution quand le jeton était absent. Depuis quelques versions, Rails fait les deux et j'ai donc retiré le code. J'ai ensuite testé avec curl, on pouvait bien poster sur la tribune sans le jeton.

    Au sujet des cookies, ça fait longtemps que l'on a ces 2 cookies :

    • linuxfr.org_session est le cookie de session qui sert à authentifier l'utilisateur (et il contient le double du jeton anti-CSRF qui sert à la comparaison)
    • remember_account_token est un cookie persistant, qui n'est présent que pour les personnes ayant coché la case « Se souvenir de moi » à la connexion.

    Quand quelqu'un ferme son navigateur, le cookie de session disparaît. La fois suivante, lorsqu'il revient sur le site, le cookie remember_account_token est utilisé pour recréer une nouvelle session et donc un nouveau cookie linuxfr.org_session.

    Pour le problème pour poster sur la tribune, je n'ai pas compris précisément ce qui pose problème mais mon hypothèse principale est que les cookies de session ont été invalidés lors de la montée de version de Rails.

    • [^] # Re: Session invalidée ?

      Posté par  . Évalué à 6.

      Je viens de vérifier avec curl. Il faut bien les deux cookies "linuxfr.org_session" et "remember_account_token" pour que le post fonctionne sur la tribune (sinon, on se prend un 302 qui n'indique aucune erreur mais le post n'apparaît pas).

      Alors qu'avant, "linuxfr.org_session" suffisait.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Session invalidée ?

        Posté par  . Évalué à 5.

        (sinon, on se prend un 302 qui n'indique aucune erreur mais le post n'apparaît pas).

        Je n'ai rien dit. Si on n'a pas remember_account_token, on est redirigé vers la page de connexion. Alors que dans l'autre cas, on est redirigé vers la page d'accueil.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Session invalidée ?

        Posté par  . Évalué à 1.

        Alors qu'avant, "linuxfr.org_session" suffisait.

        Amusant : je viens de regarder ma config, et je me rends compte que c'est l'autre cookie (remember_account_token) que j'avais mis dans olcc il y a longtemps !

        Donc je me permets de corriger ta pĥrase : avant, un seul des deux cookies suffisait ;-)

    • [^] # Re: Session invalidée ?

      Posté par  . Évalué à 1.

      Pour le problème pour poster sur la tribune, je n'ai pas compris précisément ce qui pose problème

      Le 1er problème est celui indiqué par claudex (ie. il faut les deux cookies pour poster sans l'authenticity_token et pas simplement le cookie de session)

      Le 2e problème est que l'endpoint /compte/connexion ne fournit pas le cookie remember_account_token si on ne lui passe pas le linuxfr.org_session obtenu avant la connexion (la connexion se passe bien, le problème est qu'on a juste un des cookies).

      Du coup on est coincé pour poster avec les coincoins.

  • # saikoi

    Posté par  . Évalué à -2.

    saikoi la tribune ?

  • # Erreur 400

    Posté par  . Évalué à 1.

    Bon je galère toujours à essayer de faire marcher mon client pour la tribune code ici.

    Alors si je mets des valeurs bidons dans les 2 cookies, la tribune répond bien et me renvoie sur la page de connexion :

    **** TEST 0 ****
    url: https://linuxfr.org/board
    method: POST
    headers:
    ('Message', 'test libcoin')
    ('User-agent', 'libcoin')
    ('Cookie', 'remember_account_token=invalide; linuxfr.org_session=invalide')
    response: 200
    Server: nginx/1.6.2
    Date: Thu, 28 Jun 2018 08:16:35 GMT
    Content-Type: text/html; charset=utf-8
    Transfer-Encoding: chunked
    Connection: close
    X-XSS-Protection: 1; mode=block
    X-Content-Type-Options: nosniff
    X-Served-By: 24898
    X-Revision: b087117c68f5d0b2121897881c48d68cedc6ad50
    ETag: W/"6f737b61f5b47cee1101e9d19f748dab"
    Cache-Control: max-age=0, private, must-revalidate
    Set-Cookie: linuxfr.org_session=YVlYNHJTTG1CUUI4NlNMZTVBQklJQnRkczk0clBXRzhHa1YxNDU3OXY2aFhMQnJnQ2F6Z2ZiOFYxZUxFS05Gak04WUU5QVFzSHRKWkthRExCQitDYmdyNEYrenl0d2U0a3dUelg3S1ZiMjdhRlZ5VFNzOHBBdGZ1NVFUdjBsQjhiSFVNNXVxTWozMlRUL0J0cDhnbkt3PT0tLVZXU284TUhMeG5YbW5FZ2pZajMvTlE9PQ%3D%3D--a88a95fe95c6b914d03945fc589e4b12ac78d1ca; path=/; secure; HttpOnly; SameSite=Lax
    X-Request-Id: 6954687e-dc0c-4044-9e05-6e2b7b58a84a
    X-Runtime: 0.026912
    X-Content-Type-Options: nosniff
    

    Par contre à partir du moment ou je renseigne les véritables cookies j'obtiens des erreurs 400.

    Test avec uniquement remember_account_token :

    **** TEST 1 ****
    url: https://linuxfr.org/board
    method: POST
    headers:
    ('Message', 'test libcoin')
    ('User-agent', 'libcoin')
    ('Cookie', 'remember_account_token=W1**coupé**d4')
    ERROR 400
    

    Test avec remember_account_token et linuxfr.org_session :

    **** TEST 2 ****
    url: https://linuxfr.org/board
    method: POST
    headers:
    ('Message', 'test libcoin')
    ('User-agent', 'libcoin')
    ('Cookie', 'remember_account_token=W1**coupé**d4; linuxfr.org_session=Uy**coupé**b4')
    ERROR 400
    

    Du coup je me demande si c'est pas un problème avec ma requête et non l'authentification mais je vois pas d'où ça vient (oO)

    • [^] # Re: Erreur 400

      Posté par  . Évalué à 4. Dernière modification le 28/06/18 à 10:38.

      Tes logs ne permettent pas de savoir ce que tu envois. Il faudrait que tu donne le trafic HTTP. Par exemple, voici un post valide (de tête):

      POST /board HTTP/1.1
      Host: linuxfr.org
      Cookie: remember_account_token=XXX; linuxfr.org_session=XXX
      User-Agent: libcoin
      
      board[message]=test libcoin
      

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Erreur 400

      Posté par  (site Web personnel) . Évalué à 0.

      Tu devrais regarder l'API (qui remarche, merci nono!), ce sera plus simple: https://linuxfr.org/developpeur

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Erreur 400

      Posté par  (site Web personnel) . Évalué à 3. Dernière modification le 28/06/18 à 20:00.

      J'ai bien l'impression que tu envoies le message en tant que header http alors que ça doit être un champ des données de POST.

      Il y a peut-être d'autres problèmes, mais c'est déjà quelque chose que tu dois corriger.

      • [^] # Re: Erreur 400

        Posté par  (site Web personnel) . Évalué à 3. Dernière modification le 29/06/18 à 08:19.

        Je ne sais pas si c'est toujours obligatoire, mais dans mes clients j'envoie toujours le header Referer avec linuxfr.org comme valeur. A une époque en tous cas on ne pouvait pas poster sans.

      • [^] # Re: Erreur 400

        Posté par  . Évalué à 4.

        Tout à fait ! C'était ça le problème…

        La méthode corrigée si ça interesse quelqu'un :

            def send_message(self, msg):
                data = {
                  "utf8": "✓",
                  "board[message]": msg
                }
                data = bytes(urllib.parse.urlencode(data).encode())
                req=urllib.request.Request(self.POST, method="POST")
                req.add_header("User-agent", self.agent)
                if "" != self.cookies:
                    req.add_header("Cookie", self.cookies)
                for h in req.header_items():
                    print(h)
                try:
                    res=urllib.request.urlopen(req, data)
                    return(res)
                except urllib.error.HTTPError as error:
                    print("ERROR", error.code)
                    return(error.code)
        
  • # Patte blanche

    Posté par  . Évalué à 5.

    à retrouver lui aussi dans les informations de votre navigateur.

    Comme me l’a indiqué l’un des méta-expert présent sur la tribune, il est nécessaire de cocher « Se souvenir de moi » lorsque l’on se connecte, ceci afin d’avoir accès à ce second cookie.

    Zir< est donc de nouveau en état de poster, pour relever à nouveau le niveau général de pertinence du canal bivalve historique.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.