Quand j'édite un paragraphe de dépêche, ou quand je réorganise une dépêche je vois bien le champ texte d'édition, mais une erreur se produit sur la validation.
Même chose lors de la soumission d'un bug sur http://linuxfr.org/suivi/nouveau
Les urls en erreur :
POST http://linuxfr.org/redaction/news/dix-annees-de-telephones-mobiles-libres/reorganized
POST http://linuxfr.org/redaction/paragraphs/343170
POST http://linuxfr.org/suivi
La réponse est vide, et le code d'état est 422 Unprocessable Entity
J'utilise Firefox 55.0.2 (64 bits) sur Ubuntu 14.04 LTS (64 bits)
Le problème arrive aussi avec Chromium en étant connecté ou après déconnecté.
Je fais cette tentative de soumission de ce bug avec Firefox en étant déconnecté et en ayant supprimé tous mes cookies…
# Auteur
Posté par quent57 . Évalué à 1 (+0/-0).
c'est moi l'auteur de ce bug, on dirait que la soumission de commentaire fonctionne maintenant…
[^] # Re: Auteur
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
L'erreur vient des vérifications CSRF :
Les deux navigateurs différents utilisés ont été touchés par les 422.
[^] # Re: Auteur
Posté par quent57 . Évalué à 1 (+0/-0).
Je n'ai aucune extension sous chromium (j'en ai plein sur Firefox, mais j'en conclu donc que cela ne doit pas être lié).
Vu que cela a finalement fonctionné après avoir supprimé mes cookies, peut être que c'est lié a mon compte linuxfr ?
Tiens moi au courant si je dois faire des tests spécifiques.
[^] # Re: Auteur
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
J'ai noté des rafales de requêtes quasi simultané, ça doit pouvoir jouer sur le test CSRF a priori.
(et ça semble être aussi le cas sur d'autres cas de 422 par d'autres utilisateurs)
[^] # Re: Auteur
Posté par quent57 . Évalué à 1 (+0/-0).
J'avais plusieurs onglets ouvert sur linuxfr, mais je ne me suis pas amusé à cliquer le plus vite possible sur des liens, promis !
# Solution chez Gitlab
Posté par ZeroHeure . Évalué à 2 (+0/-0).
Gitlab a le même problème (Gitlab est écrit en Rails…). Ils ont produit des patchs de contournemenct puis un patch définitif avec explication de tout le processus qui mêne au bug.
https://gitlab.com/gitlab-org/gitlab-ce/issues/35447
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Solution chez Gitlab
Posté par Bruno Michel (site web personnel) . Évalué à 3 (+0/-0).
Oui, sauf que ce n'est pas le même bug. Le bug de gitlab est déterministe : tous les utilisateurs qui se connectent d'une certaine façon sont concernés et ça arrive systématiquement pour eux. J'ai quand même été vérifié avec le débuggeur si les filtres sont dans le bon ordre, c'est bien le cas. Bref, c'est sûrement quelque chose dans le même style, mais leur correctif ne va pas nous aider.
# Même expérience
Posté par claudex . Évalué à 3 (+0/-0).
Pour info, j'avais eu le même problème il y a quelques mois. Ça s'était corrigé en virant tous les cookies (et donc, il ne se produisait pas en navigation privée).
« 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
# Autre cas signalé
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Voir le doublon https://linuxfr.org/suivi/firefox-post-en-erreur
# Plongée dans les logs
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 01 octobre 2017 à 16:55.
Entre le 21 septembre 12:20 et le 1er octobre 13:03, 341 cas identifiés de HTTP 422, tous pour la même raison, (293 POST, 31 PATCH et 17 PUT, de 69 IP différentes, avec des navigateurs différents, à n'importe quelle heure, sur un peu tous les formulaires). A priori rien de nouveau, on trouvait des HTTP 422 (supposément pour la même raison) tous les mois en 2017 et en 2016.
# Problème se résolvant avec un deco/reco
Posté par Grugru . Évalué à 1 (+0/-0).
J'ai eu ce problème en postant un commentaire, Ca a fini par fonctionner en me déconnectant reconnectant si ca peu aider…
[^] # Re: Problème se résolvant avec un deco/reco
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
C'est a priori lié à la session. On envoie une donnée pseudo-aléatoire liée à la session, et l'utilisateur doit nous la renvoyer pour comparaison. Ça échoue, soit parce que c'est une donnée valide mais trop vieille ou d'un autre formulaire qui est renvoyée par le naviqateur, soit parce que c'est une donnée corrompue pour une raison ou une autre qui est renvoyée par le navigateur, soit parce que la donnée est correctement renvoyée par le navigateur mais que côté code serveur un truc passe mal (sachant que divers navigateurs sont concernés, ça ne serait pas le plus improbable). C'est toute la question. Et donc changer la session résout le problème en faisant table-rase des données attendues.
# Toujours d'actualité
Posté par Bruno Michel (site web personnel) . Évalué à 3 (+0/-0).
Cette entrée de suivi concerne un bug qui touche des utilisateurs du site. J'ai beau cherché, je n'arrive pas à trouver la cause de la désynchronisation entre les cookies et le token CSRF soumis en formulaire. Comme je n'arrive pas à reproduire, ce n'est pas facile à débugger. Mais je continue de chercher.
[^] # Re: Toujours d'actualité
Posté par Bruno Michel (site web personnel) . Évalué à 3 (+0/-0).
J'ai l'impression que la mise à jour de Rails en version 5 a corrigé le problème. Si quelqu'un a rencontré le problème récemment, je suis intéressé pour savoir quel jour, à quelle heure et sur quelle page (même si c'est approximatif).
[^] # Re: Toujours d'actualité
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 06 juillet 2018 à 12:04.
Occurrences de HTTP 422 dans nos logs de prod :
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.