Distributor: Échec de l'autorisation // Tronquer les URL de référence

Créé le 24 juin 2019  ·  7Commentaires  ·  Source: 10up/distributor

Décrivez le bogue

Le distributeur génère des URL volumineuses qui incluent des listes potentiellement longues de publications dans la chaîne de requête de l'URL. WP inclut l'URL entière sous la forme Referrer dans l'en-tête des demandes sortantes. Avec des URL suffisamment longues (~8k+ caractères UTF-8), cela invalidera les en-têtes avec des serveurs configurés avec une limite de taille de 8kb pour les en-têtes, comme cela a été le cas dans notre cas ( wamu.org ). Les en-têtes sont brouillés et, puisqu'il s'agit de données d'autorisation, cela entraîne finalement l'échec de l'autorisation.

Étapes pour reproduire

  1. Connectez-vous à un site WP avec les mots de passe d'application et le distributeur installés.
  2. Cliquez sur Extraire le contenu.
  3. Choisissez une connexion externe configurée avec un utilisateur avec des crédits générés par le mot de passe d'application dans la liste déroulante Pull Content from .
  4. Sélectionnez un type de publication dans le menu déroulant à côté du bouton de filtre, où le type de publication est celui qui a été extrait fréquemment (ceci est important car je pense que cela affecte la taille de l'URL, en particulier une liste de publications à exclure dans la chaîne de requête ).
  5. Cliquez sur filtrer.
  6. Le message d'erreur Could not pull content from connection due to error.

Comportement attendu
Les en-têtes ne doivent pas avoir l'URL complète afin qu'ils ne soient pas altérés.

Captures d'écran

Informations environnementales

  • Appareil : MacBook Pro (13 pouces, 2018, quatre ports Thunderbolt 3)
  • Système d'exploitation : MacOS 10.14.3
  • Navigateur et version : Chrome 74.0.3729.169
  • Version distributeur : 1.4.1
  • Thème et version : 3.0.28
  • Autre(s) plugin(s) et version(s) installée(s) :

Contexte supplémentaire

Solution proposée : tronquer l'URL de référence...

add_action('http_api_curl', function($handle, $request_args, $url) {
    if (strpos($url, "wp-json/wp/v2/wamu_story") !== false || strpos($url, "wp-json/wp/v2/posts") !== false) {
        curl_setopt($handle, CURLOPT_REFERER, site_url());
    }
}, 10, 3);
bug
Source
picture superbuggy

Tous les 7 commentaires

@superbuggy bienvenue au distributeur et merci pour les commentaires ! Je marque ceci pour examen lors de notre prochaine version 1.5.0, alors restez à l'écoute pour une mise à jour.

@dkotter a-t-il une chance que vos améliorations de la page Pull Content résolvent ce problème ?

jeffpaul picture jeffpaul le 24 juin 2019
👍1

Merci @superbuggy - Je pense qu'il est tout à fait logique de tronquer l'URL de référence/référent pour l'instant, je cherche à savoir s'il est préférable de revenir à l'URL du site ou d'utiliser l'URL de la page d'administration actuelle. J'aimerais également votre avis sur la question de savoir s'il serait préférable, à long terme, d'arrêter de placer les messages exclus dans la chaîne de requête (en laissant la fonctionnalité réelle intacte) et de faire référence à une option stockée à la place.

helen picture helen le 11 juil. 2019

Après avoir approfondi un peu plus cela avec l' @dkotter , je peux déclencher cela facilement en définissant $this->sync_log = range( 0, 400 ) dans PullListTable::prepare_items() . Nous devons corriger cela, car il est très facile d'entrer dans les centaines de messages extraits, et si nous continuons de cette façon, nous allons déclencher un fatal avec post max vars. Je ne veux pas supprimer complètement cette variable, car les messages déjà extraits ne seront pas exclus, mais je ne vois pas vraiment de solution parfaite. Il y a deux choses que nous pourrions essayer de faire ici et qui, à mon avis, sont aussi bonnes que possible :

  1. Pour 1.5, tronquez $sync_log dans la méthode ci-dessus à un nombre arbitraire (peut-être 200 ?) list (en comparant avec le journal de synchronisation local) afin que la pagination soit toujours correcte. Sinon, vous courez le risque d'avoir une page contenant sensiblement moins d'éléments que les articles par page, voire aucun, ce qui entraînerait sûrement une confusion chez les utilisateurs. Je pense que c'est une UX raisonnable étant donné que nous parlons de remonter assez loin dans la pagination dans l'état par défaut - les résultats de la recherche afficheraient des lignes grisées plus tôt, mais tant que nous ne les rendons pas réellement disponibles pour le tirage, je pense que c'est bien.

  2. Pour une future version (1.6 ou 2.0 peut-être), voir sur le stockage du journal de synchronisation sur le site distant (si ce n'est déjà fait ?) pour les connexions authentifiées et son utilisation pour renvoyer les résultats à la place. Je suppose que nous devrions le stocker dans des options avec un hachage de l'URL du site distant ou quelque chose du genre. Pour les connexions non authentifiées, nous aurions toujours recours au correctif d'origine.

Des idées/objections ? Travailler sur un PR maintenant.

helen picture helen le 16 juil. 2019

@superbuggy J'ai ouvert le n° 431 pour résoudre ce problème, si vous êtes en mesure de jeter un coup d'œil et de donner un avis sur l'approche et/ou les résultats de l'interface utilisateur et comment cela vous affecte.

helen picture helen le 17 juil. 2019

Revenir avec plus de diligence raisonnable avant de fusionner le n° 431 - avec @cmmarslender sur l'assistance, cela semble être un problème de 414 Request-URI Too Large , pas un problème de taille d'en-tête. Aucun de nous n'a pu reproduire les en-têtes envoyés en plus de celui d'authentification. Je suis toujours heureux de vous aider à résoudre les problèmes de référence si vous souhaitez vous connecter directement (Slack, ou autre) à propos d'erreurs spécifiques que vous avez vues de votre côté, mais pour l'instant, je pense que mon RP est en effet la bonne solution de première phase.

helen picture helen le 18 juil. 2019
👍1

Ça a l'air bien! Dans notre cas, je viens d'ajouter dans le bloc de code ci-dessus à functions.php pour notre thème principal en tant que correctif. Je suis principalement un développeur JS et je suis plus récent sur WP, donc je n'ai pas encore une compréhension détaillée et de bas niveau de la façon dont WP utilise les URL de référence, mais ce problème 414 est tout à fait logique compte tenu de ma compréhension du problème que nous avons rencontré. Comme mesure supplémentaire, nous avons fini par simplement modifier notre configuration NGINX pour permettre aux en-têtes d'atteindre 32k.

L'histoire de la liste d'exclusion des messages sur la télécommande a également du sens pour moi. Est-ce intuitif qu'un site devrait garder une trace des messages qu'il a déjà extraits. Cela pourrait être stocké dans le tableau des options, peut-être ?

superbuggy picture superbuggy le 22 juil. 2019

Merci pour vos réponses!

superbuggy picture superbuggy le 22 juil. 2019
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

helen picture helen  ·  3Commentaires
hreimer picture hreimer  ·  5Commentaires
wisnetmaster picture wisnetmaster  ·  7Commentaires
lakrisgubben picture lakrisgubben  ·  6Commentaires
dleeward picture dleeward  ·  7Commentaires