更新履歴

アクティビティが横スクロールなしで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 のリプレイは引き続きバイト単位で完全に一致します。

プランのアップグレード時に銀行が3D Secureを要求した場合、リクエストは発生しない変更をポーリングしていました(認証を求めるプロンプトが表示されなかったため)。プラン変更フローは、初回登録時と同様にこの追加ステップを処理するようになり、アップグレードが正常に完了します。

管理者がカスタムプランを割り当てた場合、Billing / Planに「Your custom plan: {name} ({price})」とサブスクライブボタンが表示されるようになりました。これまでは、誰かに知らされるまで割り当ては表示されませんでした。

以前、BrowserはCloudflareのclearance cookieが確認された場合にのみ、防御突破ティアの30クレジットを課金していました。現在は、SiteGroundをはじめとする、システムが認識して突破したすべての防御に対して同様に課金します。また、レスポンスには defenses: { present, cleared } が含まれるため、まだ突破できていない場合でも、どのベンダーがブロックしているかを特定できます(DataDome、PerimeterX、Akamai、Incapsula、hCaptchaは現在認識されていますが、まだ突破されていません)。

ブラウザレスポンスは defenses: { present, cleared } を返すようになりました。これにより、ターゲットが実行したすべてのベンダーと、実際にクリアされたすべてのベンダーが示されます。課金も同じルールに従います。任意のベンダー(Cloudflareのみに限定されません)をクリアしたリクエストは防御の解決とみなされます。認識可能であってもまだ突破できないベンダーは present に表示され、価格が上がることはありません。

SiteGroundは多くの小規模なWordPressやWooCommerceショップのフロントとして機能しているため、そのRobot Challenge Screenは単一のサイトではなく、ターゲットのクラスとなります。unblocker: trueにより、Singleはこれをインプロセスで解決し、実際のページを返すようになりました。以前は、このクラスのターゲットに対してBrowserを起動する必要があり、ブラウザセッションのコストと待機時間が発生していました。クリアランスcookieはresponseで返されるため、リプレイは安価に保たれます。

Browserは、本文が読み取られる前にリダイレクトするチャレンジページを処理するようになりました。これにより、保護されたサイトへのrequestは空のresponseではなくコンテンツを返すようになります。

SiteGroundは、多くの小規模なWordPressおよびWooCommerceショップの前に「Robot Challenge Screen」を配置します。クリックする要素はなく、SHA-1のプルーフ・オブ・ワークです。Singleは、30クレジットのブラウザセッションではなく、2クレジットで1回のコールでこれをクリアし、実際のページを返すようになりました。これは、Singleが単独で処理する最初の非Cloudflare防御となります。