ハイライト
多くのサイトはトップページを誰にでも公開する一方で、1クリック先の全コンテンツを制限します。Autoがこのフロントドアからのアクセスに対応しました。エントリーページから発行されたセッションを取得し、それを保持した状態で目的のページをリクエストします。今週はBrowserに大きなアップデートが入りました。同じページに複数のリクエストが同時に集中した場合でもサイトのチェックボックス検証を完了し、ページがブロックされたままの場合は単一の定型文ではなく検知した内容を詳細に報告します。
新機能
Autoがセッションを要求するゲート付きページに対応
eBayのリスティングページは、FourAのどのルートからのコールドリクエストも拒否します。しかし、eBayのエントリーページが一般の訪問者に渡すcookie jarをリクエストに含めると、同じURLが開きます。ログインや借用アカウントは不要で、ブラウザのタブ上で手動実行できる操作と変わりません。
Autoがこの処理を自動化します。出口ノードがオリジンに到達したものの深層ページの取得を拒否された場合、Autoは同じ出口経由でサイトのルートを取得し、返されたcookieを保持して再リクエストを実行します。レスポンスからこの動作を確認できます。採用されたラングにはwarmupと表示されます。
重要なのはコストです。取得したセッションはポータブルなため、jarはそれを取得した出口ノードに固定されません。後続の読み取りは/api/proxyを通じてリプレイされ、2クレジットで/api/singleに到達します。これはCloudflare clearanceの記事で解説した「エスカレーション後にリプレイする」チェーンと同じ仕組みであり、cf_clearanceの代わりにベンダー自身のセッションcookieが使用されます。
意図的な制限として、リクエストごとに異なる出口で最大2回まで試行され、深層URLが失敗済みで、かつ出口が最初にオリジンへ到達できていた場合にのみ実行されます。そのため、単純にブロックしてくるサイトであっても余計なサブコールは一度に2回のみ発生し、ループすることはありません。ラダーによるラング選択の詳細はAutoの解説記事を参照してください。
Browserが重複リクエスト時のチェックボックスチャレンジをクリア
Browserは、同一ページに対する並行リクエストでもチェックボックス検証を完了できるようになりました。Turnstileで保護されたニュースサイトへの3並行リクエストでは、5.2秒、5.8秒、9.1秒を記録しています。
あわせて2つの小規模な変更も適用されました。Cloudflareは予想以上にチャレンジを再発行するため（1回目のクリックで完了しないケースが頻繁にあります）、ウィジェットが完全に消去されて初めてクリックが1回としてカウントされます。また、検証をクリアしたページは、解決の課金対象となったコール自身でdefenseSolved: trueを報告します。
ブロックされたページがソルバーの検知内容を報告
「Timeout」というエラーはレイテンシの問題を示唆しますが、大半の場合レイテンシは原因ではなく、別の出口ノードを試せば解決します。
検証サービスが試行を拒否すると、検証が再発行され、jarに独自の再試行マーカーが配置されます。Browserはそのマーカーを読み取ります。タイムアウトまで待機するのではなく約17秒で応答し、ベンダー名、実行したクリック操作、クリアランスが付与されたかどうかを返します。
Timeout after 12s: the cloudflare challenge did not complete from this exit
(2 checkbox presses, clearance granted, challenge re-issued by the site)
一方の行はリクエストを別の方法で送信するよう指示しています。もう一方は何も伝えていません。
APIレイヤーからのエラーも、より直接的な内容になりました。待機時間を超過したリクエストはtimeoutとして返され、到達できないサービスはunavailableとして返されます。リクエストでproxyを一切使用していない場合にproxyの問題として説明されることはありません。Browser呼び出しにおけるtimeout_msは、APIが受け付ける最大120秒まで正確に維持されるため、低速なターゲットに対しても設定したバジェットが適用され、ゲートウェイではなくエンジン自体の判定結果を確認できます。パラメータはAPI referenceに記載されています。
請求先情報、および発行月内におけるインボイスの修正
ブルガリアのインボイスでは、受取人欄に会社代表者（MOL）が記載されます。これまではシステム内で収集されていなかったため、その行は常に空欄になっていました。現在、請求先情報にこのフィールドが追加されています。
また、インボイス一覧テーブルでは、発行月内であり、固定された詳細情報が現在の請求プロファイルと異なるインボイスに対して「Update details」を実行できます。ダイアログには変更される各フィールドと変更後の値が表示され、インボイス番号、日付、金額は変更されないことが明記されます。確認を行うことで同意となり、当社側で記録されます。変更対象がない期間内のインボイスには「Editable until」と日付が表示されるため、編集可能な期間を後から知るのではなく、事前に確認できます。
Under the Hood
ダッシュボードが実行するすべてのスクリプトは自社オリジンから配信され、サインイン後のリダイレクト先はこのサイト上のパスのみに制限されています。
レンダリングサービスのロールアウトは1台ずつサーバーごとに実行され、各サーバーは次のサーバーに移行する前に実際のページを正常に配信する必要があります。
ステータスポータルでは、issues endpointが公開APIを介してオープンおよび解決済みの項目を配信し、ページ上の表示内容と一致させています。
原因を明示した拒否であれば1回の呼び出しで済みます。「Timeout」で終わる待機は、次に何を試すべきかの推測を強いることになり、同じコストがかかります。エラーはプロダクトの重要な接点であり、今週からその前提に基づいた対応を開始しました。