1

この質問はスーパー ユーザーにも投稿しています。私の意見では、この質問は 2 つに重なっています... CouchDB の REST-ful インターフェース用 の単純な JavaScript ラッパー


を 作成していますが、同じオリジン ポリシーの問題で立ち往生しています。

これまでのところ、Mozilla FireFox でローカルに動作するようにコードを開発してきましたが、これは概念実証としてのみです。私のサーバーは、localhost、ポート 5984 で実行されています。

Mozilla FireFox でクロスオリジン ポリシーを無効にするには、PrivilegeManagerを使用できますが、サーバーに対して PUT リクエストを実行できないという意味では、中途半端なだけです...

/*
 * Including this in my JavaScript file only seems to disable cross-origin
 * policy checks for POST and GET requests in Mozilla FireFox.
 * PUT requests fail.
 */

netscape.security.PrivilegeManager.enablePrivilege(
    "UniversalBrowserRead UniversalBrowserWrite"
);



サーバーの場所を非表示にするようにサーバーを構成して、同じ生成元ポリシーの問題を回避するためにブラウザー固有の回避策を実装する必要がないようにする方法はありますか? そうでない場合: 同一オリジン ポリシーを完全に無効にするブラウザの回避策はありますか?

4

2 に答える 2

3

残念ながら、同一オリジン ポリシーを無効にするブラウザの回避策は、重大なセキュリティ バグとして扱われ、できるだけ早く修正される可能性があります。

同一生成元ポリシーをバイパスせずに、同一生成元ポリシー内で動作する方法を考え出すことができるかどうかを確認してください。

サンプル スクリプトをターゲット サーバーに提供できますか? ユーザーのコンピューター上のローカル スクリプトが変更内容をアップロードした後、ターゲット スクリプトをサーバーにロードするリフレクション スクリプトを作成できますか?

同一生成元ポリシーをバイパスする必要のない適切な解決策があるはずです。それを回避する方法をハックしようとすることは、将来のブラウザでコードが正しく動作しないようにするための良い方法です。

于 2010-09-07T19:13:46.183 に答える
0

仮想化されたCouchDBサーバーに接続するローカルhtmlファイルで自動テストを実行しようとして、私もその問題に苦労しました。これが私の解決策です:

サーバーで CORS を有効にできない場合の最も単純なソリューションの小さな実装を作成 (およびオープン ソース化) しました。

.js ファイルと .html ファイルをターゲット サーバーにアップロードする必要があります (必要に応じて、任意のセキュリティ メカニズムを使用してこのファイルへのアクセスを制限できます)。または、html ファイルのいくつかの単純なパラメーターを変更して、ドメインで制限することもできます。

あなたのページでは、同じスクリプトを使用して、ホストされている .html が読み込まれる非表示の iframe を作成し、window.postMessage() を使用してその iframe を介して特定のメソッド (RPC のようなもの) をプロキシします。デフォルトでは、jQuery ajax メソッドはなしでプロキシできます。余分な構成。

これらすべてを1行のjsコードで実行します:)

GitHub の FrameProxy

（自由に使用してフォークしてください！）

于 2012-01-06T14:25:13.167 に答える