10

これがケースです:
ページ A には iframe B が含まれ、B には iframe C が含まれ、A と B は同じドメインの下にあり、C は別のドメインの下にあります。
C は、Fragment Id Messaging を使用してクロスドメイン通信を解決するために、「#」に続く追加情報を使用して親 B の位置をリセットしようとします。

IE6/7/8 はこのケースで問題なく動作しますが、Firefoxはエラー メッセージ [プロパティへのアクセスが拒否されました " コード: "1010 ]でparent.location設定をブロックします。しかし、B がトップ ウィンドウである場合、つまり A がない場合、Firefox も有効です。 私には奇妙です...助けてもらえますか？ ありがとうございました！



4

2 に答える 2

15

歴史的に、どのウィンドウも他のウィンドウの場所を変更する可能性があります。これは、とりわけ、ログインiframeをウィンドウに埋め込むことが安全ではないことを意味するため、問題であることが判明しました（悪意のあるサイトが、ログインiframeをなりすましバージョンに置き換える可能性があるため）。HTML5とほとんどのブラウザが祖先のポリシーについて共通の合意に達したときまで、時間の経過とともに、ブラウザウィンドウの場所の変更にさらに制限が適用されてきました。一言で言えば、HTML5仕様を言い換えると、ウィンドウAは別のウィンドウBの場所を変更できます。

  • AとBの場所は同じ起点を持っています。つまり、同じスキーム、ホスト、ポート（http、stackoverflow.com、80など）を持っているか、または
  • Bはトップレベルのウィンドウであり、AはB内のある深さでネストされたフレーム内のウィンドウ（直接の子、子の子など）、または
  • Bはを使用して開かれたwindow.openウィンドウであり、AはBを開いたウィンドウの場所を変更できます（つまり、BはAによって開かれたポップアップ、Aによって開かれたポップアップウィンドウ、またはそれ以上の深さ）、または
  • Bはトップレベルのウィンドウではありませんが、その親ウィンドウ、その親の親ウィンドウ、または同様の量の親子関係では、そのウィンドウとAの位置は同一生成元です。

（同じ起源はこれよりも複雑ですが、上記の埋め込まれた説明はその本質を捉え、最も一般的なケースをカバーしています。）

このポリシーでは、CがAの場所を変更し、AがBまたはCの場所を変更する場合がありますが、CはBの場所を変更しない場合があります。これを回避する必要がある場合は、ページAの場所を次のように変更する必要があります。必要に応じてBを変更するもの。または、ページBに自分の場所を変更するように依頼することもできます。

必ずしも役立つとは限りませんが、それが有益であることを願っています。ブラウザのセキュリティモデルは、進化したものほど設計されていませんでした。HTML5での最近の作業によってのみ、これらのブラウザ間の不整合に対処するために正確に特定されています。

とはいえ、IE7とIE8が機能することに驚いています。上記のポリシーは、主にIE7が実装したポリシーに基づいていると理解していました。

于 2009-07-21T18:14:11.903 に答える
0

Cから、を使用してBのウィンドウにアクセスできますwindow.top。

試す、var B = window.top; B.location = "...";

于 2009-07-21T04:07:40.653 に答える