ハイライト
多くのサイトはトップページを誰にでも公開し、1クリック先のページはすべてロックしている。Autoは正面から入るようになった。エントリページが発行するセッションを取得し、それを保持したまま目的のページを要求する。今週、Browserはより重い処理に対応した。複数のリクエストが同じページに同時アクセスした際にCloudflareのチェックボックスチャレンジをクリアし、ページがブロックされたままの場合は単一の単語ではなく確認した内容を報告するようになった。
新機能
Autoがセッション背後にあるゲート付きページを開く
eBayの出品ページは、我々の持つすべてのルートにおいてコールドリクエストを拒否する。eBay独自のエントリページが訪問者に渡すcookie jarをリクエストに含めると、同じURLが開く。ログインも、借用したアカウントも不要であり、ブラウザのタブで手動でできることと何ら変わりはない。
Autoは現在、これを自動的に実行する。exitがオリジンに到達しても深いページへのアクセスを拒否された場合、Autoは同じexitを介してサイトのルートを取得し、返されたcookieをすべて保持して再度リクエストを行う。レスポンスはこの処理が発生したことを通知する。成功したラダーの段階にはwarmupと表示される。
しかし、興味深いのはコスト面である。このセッションはポータブルな状態で返されるため、jarはそれを取得したexitに固定されない。後続の読み取りは/api/proxyを通じてリプレイされ、2クレジットで/api/singleに着地する。これはCloudflareのクリアランスについて我々が以前書いたエスカレートからリプレイへのチェーンと同じであり、cf_clearanceの代わりにベンダー自身のセッションcookieが使用される。
これは意図的に制限されている。1リクエストにつき2回のみ、異なるexitを使用し、深いURLへのアクセスがすでに失敗した場合、かつ最初にexitがオリジンに到達した場合にのみ実行される。したがって、単に我々をブロックするサイトでは、ループではなく、2回の追加サブコールが1度だけ発生する。ラダーがその段階をどのように選択するかについての詳細は、Autoの解説に記載されている。
Browserがリクエスト重複時にチェックボックスチャレンジをクリアする
Browserは、同じページに対する同時リクエストにおいて、Cloudflareのチェックボックスウィジェットを解決するようになった。Turnstileの背後にあるニュースサイトで同時に3つ実行した場合の時間は、5.2秒、5.8秒、9.1秒であった。
これに伴い、2つの小さな変更が追加された。Cloudflareは予想以上に頻繁にチャレンジを再発行するため(最初のクリックで処理が終わらないことが多い)、ウィジェットが実際に消えた時点で初めてクリックがカウントされる。また、クリアされたページはそれをクリアしたコールにおいてdefenseSolved: trueを報告し、これは解決に対して課金されるのと同じコールである。
ブロックされたページがソルバーの確認内容を報告する
「Timeout」はレイテンシを示している。多くの場合、レイテンシは問題ではなく、解決策は別のexitにある。
Cloudflareが解決を拒否すると、チャレンジを再発行し、独自の再試行マーカーを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)
これらの行の1つは、requestを別の方法で送信するよう指示します。もう1つは何も教えてくれません。
API層からのエラーもより直接的になりました。待機時間を超えたrequestはtimeoutとして返され、到達できないサービスはunavailableとして返されます。requestがproxyを全く使用していない場合、どちらもproxyの問題としては記述されません。 Browser呼び出しのtimeout_msはAPIが許容する最大120秒まで尊重されるため、遅いターゲットでも設定したバジェットが適用され、gatewayの判断ではなくエンジン自体の結果を読み取ることができます。パラメータはAPI referenceに記載されています。
請求の詳細と、発行月内の請求書の修正
ブルガリアの請求書は受取人欄に会社の代表者(MOL)を記載します。システム内でこれを収集する仕組みがなかったため、この行は常に空になっていました。現在、請求の詳細にはこのフィールドがあります。
請求書テーブルでは、発行月内で、確定した詳細が現在の請求プロファイルと異なる請求書に対して詳細の更新を提供します。ダイアログには、変更される各フィールドと変更内容が明記され、番号、日付、金額は変更されないことが明記されます。これを確認することはユーザーの同意となり、システムに記録されます。変更点のない期間内の請求書には「編集可能期限」とその日付が表示されるため、後で気付くのではなく、視覚的に確認できる期間となります。
内部の仕組み
Dashboardが実行するすべてのスクリプトは自社のオリジンから提供され、サインイン後はこのサイトのパスにのみ戻ります。
レンダリングサービスのロールアウトは1台のサーバーごとに進行し、各サーバーは次のサーバーが処理される前に実際のページを提供する必要があります。
ステータスポータルでは、issues endpointはページにリストされている内容に合わせて、パブリックAPIを通じてオープンおよび解決済みのアイテムを提供します。
理由を明示する拒否は1回の呼び出しです。「Timeout」で終わる待機は、次に何を試すべきかの推測であり、同じ価格が支払われます。エラーは製品のサーフェスであり、今週から私たちはエラーをそのように扱い始めました。