更新履歴

多くのサイトでは、エントリページを公開する一方で、下層のページは制限しています。Autoは、エントリページが発行するセッションを受け取り、それを保持して下層のURLをリクエストするようになりました。レスポンス内のwarmupにより、その実行結果が通知されます。

Browserのrequestに対してtimeout_msを最大120秒に設定すると、その設定時間全体で実行されます。これにより、応答の遅いターゲットにも指定した時間が割り当てられ、エンジン自身の判定結果を取得できます。

同一ページへの同時リクエストにおいて、ブラウザがCloudflareのチェックボックスチャレンジを解決するようになりました。また、チャレンジが完全に消滅して初めてプレスがカウントされます。同時に3つのリクエストを行った場合、5から9秒でクリアされます。

Playgroundはターゲットからのレスポンスをレンダリングするようになりました。これには大きなcookieを設定するサイトも含まれます。また、API endpointは常にJSONで応答します。

eBayの保護されたページは、訪問者をArgon2 proof-of-workチャレンジにリダイレクトします。Singleはこれを1回のコールで解決し、フォールバックパスで約360クレジットかかっていたところを、2クレジットで実際の出品を返すようになりました。eBayでフルプライスを支払っていたのであれば、それはもう終わりました。

ターゲットが異なるURLパスにリダイレクトした場合、ページが取得できているにもかかわらず、以前のBrowserは「No response received」を返していました。この問題は修正され、リクエストはナビゲーションの遷移先に追従するようになりました。eBayやリダイレクトを多用するショップ、チャレンジページへ3xxを返すサイトなども、現在すべて正常に動作します。

以前は何も報告されなかった(またはブロックを誤ってCloudflareによるものとしていた)場合でも、レスポンスでakamaiおよびebay-splashuiを報告するようになりました。再試行戦略を選択するためにコードがdefense.vendorで分岐する場合、これら2つの名前が正しく表示されるようになります。

アクティビティが横スクロールなしで14インチMacBookに収まるようになり、すべての列の値を保持します。詳細パネルはタブ付きペイン (Request、Response headers、Response body) になり、900px下までスクロールしなくても上部で結果を確認できます。ツールチップはポインターに追従し、完全なURLを表示します。

メソッド列は、API層が受け取ったメソッドとして常にPOSTを表示するのではなく、リクエストボディから実際の動詞（GET、POST、PUTなど）を読み取って表示するようになりました。また、Playgroundでの呼び出しではSendをクリックしたユーザーのブラウザIPも記録されるため、共有アカウントでも誰が実行したかを特定できます。

FourA MCP 0.6.0では、エージェントがリクエストで提示するブラウザを選択できるようになりました。foura_singleおよびfoura_proxyは、browser、os、version、またはGET /api/profilesの公開カタログにある正確なprofile IDを受け入れます。これらはすでにアップストリームへ向かうリクエスト内に含まれて送信されるため、追加の呼び出しは発生しません。省略した場合、リクエストはこれまで通り最新のGoogle Chromeを提示します。カタログが提示できない組み合わせは、利用可能なものをリストしたエラーとして返されるため、選択していないブラウザとしてリクエストが送信されることはありません。

ターゲットがボットチェックを実行した場合、両方のツールがdefenseを返すようになりました。defense.solved: falseは、本文が要求したコンテンツではなくチャレンジページである可能性があることを意味します。これは、ブロックページをデータとして解析するのではなく、別のブラウザで再試行するかエスカレーションするためのシグナルとなります。

同リリースの修正点: unblockerの説明ではデフォルトがオフとされていました。実際には常にオンであったため、リクエストにはすでに完全なブラウザヘッダーセットが含まれていました。公開されたスキーマは、現在の実際の動作と一致するようになりました。

飽和状態のインスタンスはヘルスチェックに3から10秒かかりますが、正常なインスタンスは9から225ミリ秒で応答し、以前はどちらも正常として表示されていました。現在は遅い状態がdegradedとして表示され、インスタンス自体の理由が保持されるため、リクエストが失敗する前の、1つのサーバーが遅くなっている段階で問題を把握できます。Autoも監視対象となり、成功するたびにトリガーされる一般的な制限ではなく、実際のハードな解決にかかる時間に合わせて制限が設定されています。

profile パラメータは、/api/single および /api/proxy において、どのブラウザとして認識させるかをアンブロッカーに指示します。正確なプロファイルID (firefox147 や chrome146 など) を渡すか、browser + os + version により、一致する最新の組み合わせに解決させることができます。GET /api/profiles は現在のカタログ (5つのブラウザファミリにわたる79のプロファイル) を返すため、古くなるリストをハードコードする必要はありません。Dashboardのプレイグラウンドでは、同じピッカーを3つの連動するセレクトボックスとして提供しています。

Dashboard Playgroundに、OS、ブラウザ、バージョン用の3つのカスケード選択が追加され、プロファイルカタログからライブで取得されるようになりました。任意の2つを選択すると、3つ目は実際に解決可能なものに絞り込まれます。プロファイルを選択するとunblockerがオンになります。これは、これなしではAPIがプロファイルを拒否するためです。

サービスはすべてのインスタンスが失われ、requestの送信先がまったく存在しない状態でのみダウンとしてカウントされるようになりました。通常のローリングデプロイは、ステータスページでインシデントとして表示されなくなりました。

unblockerが送信するデフォルトのシグネチャは、スクレイパーがハードコードしていた古いバージョンではなく、最新のメジャーバージョンになりました。古いメジャーバージョンに対して静的なブロックページを返し始めていたサイトも、SingleおよびBrowserでは実際のページを返すようになります。両製品は同時にアップデートされたため、BrowserからSingleへの cf_clearance のリプレイは引き続きバイト単位で完全に一致します。