バグを説明する
ディストリビューターは、URLのクエリ文字列に投稿の潜在的に長いリストを含むいくつかの大きなURLを生成します。 WPは、アウトバウンド要求のヘッダーにURL全体をReferrer
として含めます。 十分な長さのURL(〜8k + UTF-8文字)を使用すると、この場合( wamu.org
)のように、ヘッダーのサイズ制限が8kbに構成されているサーバーのヘッダーが無効になります。 ヘッダーが文字化けし、データを認証するため、最終的に認証が失敗します。
再現する手順
Pull Content from
ドロップダウンから、アプリケーションパスワードによって生成された資格を持つユーザーで構成された外部接続を選択します。Could not pull content from connection due to error.
予想される行動
ヘッダーが文字化けしないように、ヘッダーには完全なURLを含めるべきではありません。
スクリーンショット
環境情報
追加のコンテキスト
提案された解決策:リファラーURLを切り捨てます...
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);
@superbuggyディストリビューターへようこそ、フィードバックをありがとう! 今後の1.5.0リリースでレビュー用にタグを付けているので、アップデートにご期待ください。
@dkotter [コンテンツのプル]ページを改善することでこの問題が解決する可能性はありますか?
ありがとう@ superbuggy-今のところリファラー/リファラーURLを切り捨てるのは間違いなく理にかなっていると思います。サイトのURLに戻るのが良いのか、現在の管理ページのURLを使用するのが良いのかを検討しています。 また、除外された投稿をクエリ文字列に押し込むのをやめ(実際の機能はそのままにして)、代わりに保存されたオプションを参照する方が長期的には良いかどうかについてのご意見をお待ちしております。
@dkotterの助けを借りてこれをもう少し掘り下げた後、 PullListTable::prepare_items()
$this->sync_log = range( 0, 400 )
を設定することで、これを簡単にトリガーできます。 プルされた数百の投稿に入るのは本当に簡単なので、これを修正する必要があります。この方法を続けると、post maxvarsで致命的なトリガーが発生します。 この変数を完全に削除したくないのは、すでにプルされた投稿が除外されないためですが、完全な修正は実際には見られません。 ここで試すことができる2つのことがありますが、それは私が得るのと同じくらい良いと思います。
1.5の場合、上記のメソッドの$sync_log
を任意の数(おそらく200?)に切り捨てて、プルするコンテンツの少なくとも最初の数ページが正確であり、それ以降はグレー表示されるようにします。 (ローカル同期ログと比較して)テーブルを一覧表示して、ページ付けが正しいままになるようにします。 そうしないと、ページごとの投稿よりもアイテムが著しく少ない、またはまったくないというリスクがあり、ユーザーの混乱につながることは間違いありません。 デフォルト状態でページ付けをかなり前に戻すことについて話していることを考えると、これは合理的なUXだと思います-検索結果は以前にグレー表示された行を表示しますが、実際にプルできるようにしない限り、それはそうだと思いますわかった。
将来のリリース(おそらく1.6または2.0)については、認証された接続の同期ログをリモートサイトに保存し(まだ行っていない場合)、代わりにそれを使用して結果を返す方法を参照してください。 リモートサイトのURLなどのハッシュを使用してオプションに保存する必要があると思います。 認証されていない接続については、元の修正にフォールバックします。
何か考え/異議はありますか? 現在PRに取り組んでいます。
@superbuggyアプローチやUIの結果、およびそれがどのように影響するかを見て意見を述べることができれば、これに対処するために#431を開きました。
#431を-アシストの@cmmarslenderとマージする前に、より多くのデューデリジェンスで戻ってきましたが、ヘッダーサイズの問題ではなく、 414 Request-URI Too Large
問題のようです。 どちらも、認証されたヘッダー以外に送信されたヘッダーを再現できませんでした。 自分の側で見た特定のエラーについて直接接続したい場合(Slack、または何がありますか)、リファラーの問題を追跡するのを喜んでお手伝いしますが、今のところ、私のPRは確かに正しい最初のフェーズの修正だと思います。
いいですね! 私たちの場合、ホットフィックスとしてメインテーマのfunctions.php
に上記のコードブロックを追加しました。 私は主にJS開発者であり、WPを初めて使用するため、WPがリファラーURLをどのように使用するかについての詳細な低レベルの把握はまだありませんが、 414
問題は、発生した問題。 追加の手段として、ヘッダーが32kになるように、NGINX構成を変更するだけで済みました。
リモートの投稿除外リストの話は私にも意味があります。 サイトがすでに引き込んだ投稿を追跡する必要があることを直感的に感じます。これはオプションテーブルに保存できますか?
ご回答ありがとうございます!