ハイライト
ダッシュボード上で直接、自身のAPIキーを使用してリクエストの作成、送信、リプレイができるようになりました。新しいプレイグラウンドは3つの製品すべてに対応し、実行間でCookie、プリセット、履歴を保持します。あわせて2件の信頼性修正もリリースしました。数週間にわたりサイレントに品質低下していたunblocker: trueの修正(エンドツーエンドで正常に動作するよう復旧)と、BrowserによるCloudflareのパッシブチャレンジcf_clearance Cookieの安定した取得対応です。
新機能
ダッシュボード プレイグラウンド
/dashboard/#playgroundが本格的なワークベンチになりました。3つの製品タブ(Single、Proxy Finder、Browser)、URLバー、headers、bodyを備え、各製品固有のフラグが実際のスキーマに合わせて公開されています。リクエストを送信すると、JSON、HTML、テキストの各表示モードでレスポンスが描画されます。Ctrl/Cmd+Kでレスポンスペイン内を検索できます。大量のHTMLを確認する際は、レスポンスをフルビューポートに拡大表示できます。
自分たちが使いたい形を追求して実装した主な機能は以下のとおりです。
- 受信したCookieはホストごとのjarに保存されます。同じホストへの次回のリクエストに自動で付与され、送信前に任意のCookieの確認、編集、削除が可能です。
- 稼働中プロキシレールには、Proxy Finderの実行成功で返されたすべてのproxy idが収集されます。「use」をクリックするだけで、手入力することなくそのプロキシをSingleやBrowserのリクエストで再利用できます。
- リクエストをプリセットとして保存できます。履歴ダイアログから直近20件の実行をリプレイ可能です。
- cURL再現機能により、同じリクエストをターミナルから送信するための正確なコマンド(
x-api-keyを含む)が表示されます。
プレイグラウンドは有効期間の短い内部トークンに署名するため、プレーンテキストのキーがダッシュボード外部へ送信されることはありません。クォータ、メトリクス、last_used_atは、自身のコードからリクエストを送信した場合と同様に、選択したキーに対してカウントされます。
unblocker: trueがエンドツーエンドで再び動作
ここ数週間、SingleおよびProxy Finderにおけるunblocker: trueを指定したリクエストの品質がサイレントに低下していたビルドの問題を特定しました。ブラウザプロファイルが実際には組み込まれていない状態でビルドがリリースされていたため、ブラウザシグネチャを持つべきリクエストが汎用のrequestシグネチャで送信されていました。その結果、本来通過できるはずのサイトでブロックが発生していました。
修正はデプロイ済みです。以前はBrowserが必要だったチェックページ配下の3件を含む、11件の実環境ターゲットでエンドツーエンドの検証を完了しました。Single単体でこれらを通過できます。Proxy Finder + Browser + Singleを連携させたフロー(プロキシを検出し、Browserからcf_clearance Cookieを取得し、そのCookieと同じプロキシを指定してSingleでページリクエストを送信)により、1回の往復で完全なHTMLが返されます。
本件は当社の不手際によるものです。unblocker: trueはリリース時点では動作していましたが、定期リビルドの際に気付かれずに破損していました。過去数週間に保護対象サイトへunblocker: trueを指定してリクエストを送信し、200を期待したところで403が返されていた場合はこれが原因です。再度お試しください。
BrowserがCloudflareのパッシブJavaScriptチャレンジに対応
Cloudflareには2つのチャレンジモードがあります。アクティブモード(HTTP 403とインタースティシャル画面)にはすでに対応していました。より厄介なのはパッシブモードです。ページは即座に200を返しますが、Cloudflareがクライアントのフィンガープリントを採取する非同期JavaScriptプローブを挿入し、その完了後に初めてcf_clearance cookieを発行します。今回の修正前は、プローブが完了する前にBrowserがレスポンスを確定させていたため、クリアランスcookieがjarに保存されませんでした。
現在、Browserは明示的にSet-Cookieイベントをリッスンし、ボディ内にパッシブチャレンジのマーカーを検出した場合はcf_clearanceを待機します。ポーリングや固定の猶予時間は不要で、Cloudflare以外のサイトで余計な待機時間が発生することもありません。テストスイート内の12の実ドメイン(うち3つはパッシブパス)において、クリアランスcookieを確実に取得できるようになりました。
APIエッジにおけるSSRFの脆弱性を解消
有効なpk_live_... APIキーを持っているからといって、当社のプライベートネットワークへのアクセスが許可されるわけではありません。APIは、ホスト名リテラルまたはDNS解決結果がRFC 5735、6598、またはIPv6予約ブロックに該当するターゲットを拒否するようになりました。第2の防衛線として、すべてのバックエンド製品でも同様のチェックが実行されます。
表面的な動作に変化はありません。内部ネットワークへのプローブを、TCPハンドシェイクが完了する前に遮断します。
ブログのソーシャルプレビューの個別化とページネーションの修正
各ブログ記事は、記事タイトルと抜粋をブランドカード上に描画した個別のOpen Graph画像を生成するようになりました。Discord、LinkedIn、Slack、Twitterにfoura.ai/blog/...のリンクを貼り付けると、汎用のフォールバック画像ではなく記事固有のプレビューが表示されます。
ブログインデックスのページネーションに潜んでいた不具合も修正しました。「Older」ボタンを押すと1ページ目に戻ってしまう状態でした。パスベースのURL(/blog/page/N/)に再構築し、スマートウィンドウを備えた番号付きナビゲーションを追加したほか、ページネーションされたシリーズ用の適切なrel=prev/nextリンクタグを実装しました。古い?page=N URLは新しい形式へ301リダイレクトされるため、過去にクロールされた情報が失われることはありません。
内部実装について
Model Context Protocolをサポートする各種LLMツール向けに、当社のMCPサーバーをmcp.foura.aiで公開しました。認証には、REST APIで使用しているものと同じpk_live_... Bearerトークンを使用します。3つの製品(Single、Proxy Finder、Browser)をツールとして公開し、いくつかのプロンプトも提供しています。FourAをClaude CodeやMCP対応エージェントに組み込む場合、ローカルブリッジを実行する必要はもうありません。
以前のプレイグラウンドが簡素だったためにダッシュボードの利用を見送っていた方は、ぜひ今週お試しください。現在では、APIターゲットに対して問題が発生した際に、私たち自身も調査用として使用しているインターフェースです。