7

AJAX 方式でサーバーに JSON データを照会する Web ベースのツールに問題があります。正しく動作していません - 返された結果はしばしば私が望むものではなく、サーバーがリクエストを処理するのに多くの時間を待つ必要があります.

実のところ、私は常に同じデータ (正確には数人程度) が返されることを望んでいるので、サーバーの応答を偽造することを考えました。いくつかの方法でこれを達成しようとしましたが、成功しませんでした。

Chrome の WebRequest 機能を使用してみました。拡張機能を用意し、JSON エンコードされたデータ URL にリクエストをリダイレクトしました。それは機能しましたが、Chrome のアドレス フィールドにアドレスを手動で入力した場合のみでした。Web アプリがアドレスにアクセスしようとすると、リダイレクトがサイレント モードで失敗しました。私はすぐに Access Origin の制限について考え、すぐに Access-Control-Allow-Origin ヘッダーを送信する Web サーバーをセットアップしました。

残念ながら、これもうまくいきませんでした。手でアドレスを入力すると、サーバーがクエリされ、正しい JSON が返されましたが、アプリではリクエストが... 黙って失敗しました。Chrome はサーバーにクエリを実行していないため、可能性のある Access-Control-Allow-Origin ヘッダーを完全に無視しているように見えました。問題のあるリクエストをアプリのドメイン内のランダムな URL にリダイレクトしたときに、Chrome が URL のみを分析する可能性は十分にあります。

また、同じ方法を使用して、ドキュメントに静的にリンクされている (たとえば、標準の script タグを介して含まれている) アプリの JavaScript ファイル全体を偽造しようとしました。私は惨めに失敗しました-リダイレクトは、最初の試行で失敗したように、静かに失敗しました。

私の問題に対する一般的な解決策は、サーバー出力を変更するある種のプロキシを使用することですが、それはできません。サーバーがリクエストを処理するのを数分待ちたくありません。ちなみに、このアプリには HTTPS 経由でのみアクセスできます。

ハードコーディングされた JSON をアプリに供給する他の方法はありますか? それとも、何かが足りないのでしょうか？

「catblock」の例に基づくEDITプラグインコード：

chrome.webRequest.onBeforeRequest.addListener(
function(info) {
  console.log("AJAX call intercepted: " + info.url)
  return {redirectUrl: 'data:application/json,"test"'};
},
// filters
{
  urls: [
  "*://address.to.the.js.file.requested"
]
}, ['blocking']);

マニフェスト ファイル、ドメインのみを権限セクションに追加しました。

{
"name": "CatBlock",
"version": "1.0",
"description": "I can't has cheezburger!",
"permissions": ["webRequest", "webRequestBlocking", 
              "*://some.domain.com/*"],
"background": {
  "scripts": ["background.js"]
},

"manifest_version": 2
}

編集 2: これは、Chrome の開発者コンソールのネットワーク パネルのスクリーンショットで、リクエストがサイレントにキャンセルされることを示しています。 コンソールのスクリーンショット コンソールのスクリーンショット

4

2 に答える 2

3

これを行うにはいくつかの方法があります。

最も簡単な方法は、Fiddlerを使用する ことです。ロシア語を知っているか、ブラウザにまともな翻訳機能がある場合は、この記事を読むことができます。または、以下に英語のマニュアルへのリンクがいくつかあります。

このスクリーンショットが答えですここに画像の説明を入力

Chrome のAccess-Control-Allow-Origin について - また、私の拡張機能は完全に単純で (応答ヘッダーに「Access-Control-Allow-Origin: *」を追加するだけです)、機能を開発するときにこのエラーを回避できるようにします。Fiddler でも同じことができます。chrome では、開発者キー「chrome --disable-web-security」で Chrome を実行できます。「Access-Control-Allow-Origin」のエラーも削除されます。

于 2013-02-11T18:17:59.127 に答える
1

私の理解が正しければ、あなたは JSON 応答を生成するサーバーを制御できます。その場合、 Chrome 拡張機能なしで、正しい CORS ヘッダーで動作する AJAX (XMLHTTPRequest) 要求と応答を取得できる必要があります。

私の経験によると、失敗したクロスドメイン XHR リクエストは、Chrome では「黙って」失敗するようにしか見えませんが、コンソールをよく見ると、次のようなエラー メッセージが表示されます。

XMLHttpRequest はhttp://example.com/yourJSONfile.jsonを読み込めません。オリジンhttp://your-app-domain.com:80は Access-Control-Allow-Origin で許可されていません。

このメッセージは誤解を招く可能性があります。これは、CORS 関連のエラーが発生した場合 (Access-Control-Allow-Origin が正しく設定されていても) 表示されるためです。また、ネットワーク タブには、XHR のリクエスト ヘッダーとレスポンス ヘッダーが表示されます。

ここで、CORS ヘッダーについて話しましょう。どの CORS ヘッダーが必要かを正確に判断するには、リクエストの AJAX オプションまたは HTTP リクエスト ヘッダーを確認する必要がありますが、現時点で私が知る限り、「Access-Control-Allow-Origin: *」では不十分な場合があります。成功: リクエスト ヘッダーによっては (現時点では認識していないため、以下は単なる例です)、次のような追加の CORS ヘッダーが必要になる場合があります。

"Access-Control-Allow-Methods": "OPTIONS, GET, POST"

"Access-Control-Allow-Headers": "content-type, accept, origin"

また、デバッグの目的で、次を有効にすると役立ちます。

"Access-Control-Expose-Headers": "Access-Control-Allow-Origin"

[ネットワーク] タブで CORS 関連の応答ヘッダーを確認できるようにします。

于 2013-02-19T10:00:30.400 に答える