478

<base>HTMLタグ が実際にどこでも使われているのを見たことがありません。その使用に落とし穴がありますか?それは私がそれを避けるべきであることを意味しますか?

現代の本番サイト(または他のサイト)で使用されていることに気づかなかったという事実は、私のサイトのリンクを単純化するための便利なアプリケーションがあるように見えますが、私はそれを嫌がります。


編集

ベースタグを数週間使用した後、ベースタグを使用することで、最初に表示されたものよりもはるかに望ましくないいくつかの主要な落とし穴を見つけることになりました。基本的に、ベースタグへの変更href='#topic'href=''ベースタグの下での変更は、デフォルトの動作とは非常に互換性がなく、デフォルトの動作からのこの変更により、制御できないサードパーティのライブラリの信頼性が非常に低くなる可能性があります。 予期しない方法で、デフォルトの動作に論理的に依存するためです。多くの場合、変更は微妙であり、大規模なコードベースを処理するときにすぐには明らかでない問題につながります。それ以来、私が経験した問題を以下に詳述する回答を作成しました。したがって、の広範な展開をコミットする前に、リンクの結果を自分でテストしてください。これ<base>が私の新しいアドバイスです。

4

18 に答える 18

267

タグを使用するかどうかを決定する前に、<base>タグがどのように機能するか、何に使用できるか、どのような影響があるかを理解し、最終的に長所/短所を上回る必要があります。


このタグは、すべて<base>のリンクの現在のコンテキストを気にする必要がないため、主にテンプレート言語での相対リンクの作成を容易にします。

あなたは例えばすることができます

<base href="${host}/${context}/${language}/">
...
<link rel="stylesheet" href="css/style.css" />
<script src="js/script.js"></script>
...
<a href="home">home</a>
<a href="faq">faq</a>
<a href="contact">contact</a>
...
<img src="img/logo.png" />

それ以外の

<link rel="stylesheet" href="/${context}/${language}/css/style.css" />
<script src="/${context}/${language}/js/script.js"></script>
...
<a href="/${context}/${language}/home">home</a>
<a href="/${context}/${language}/faq">faq</a>
<a href="/${context}/${language}/contact">contact</a>
...
<img src="/${context}/${language}/img/logo.png" />

値はスラッシュで終わることに注意してください<base href>。そうでない場合は、最後のパスを基準にして解釈されます。


ブラウザの互換性に関しては、これはIEでのみ問題を引き起こします。タグは<base>HTMLで終了タグがないように指定されているため</base>、終了タグなしで使用するのは合法<base>です。ただし、IE6は別の方法で考え、タグののコンテンツ全体がHTMLDOMツリーの要素の子として配置されます。これにより、Javascript / jQuery / CSSで一見説明できない問題が発生する可能性があります。つまり、HTML DOMインスペクターで間に(と)があるはずであることがわかるまで、のような特定のセレクターでは要素に完全に到達できません。<base><base>html>bodybasehead

一般的なIE6の修正は、IEの条件付きコメントを使用して終了タグを含めることです。

<base href="http://example.com/en/"><!--[if lte IE 6]></base><![endif]-->

W3バリデーターを気にしない場合、またはHTML5を既に使用している場合は、それを自分で閉じることができます。すべてのWebブラウザーはとにかくそれをサポートします。

<base href="http://example.com/en/" />

<base>タグを閉じると、WinXP SP3上のIE6の狂気が即座に修正され、無限ループ内<script>の相対URIを持つリソースが要求されます。src

<base>タグでまたはなどの相対URIを使用すると、IEの別の潜在的な問題が発生し<base href="//example.com/somefolder/">ます<base href="/somefolder/">。これはIE6/7/8では失敗します。ただし、これはブラウザのせいではありません。タグで相対URIを使用すること<base>は、それ自体が間違っています。HTML4仕様では、絶対URIである必要があると規定されているため、 http://orhttps://スキームで始まります。これはHTML5仕様で削除されました。したがって、HTML5を使用し、HTML5互換のブラウザのみをターゲットにする場合は、<base>タグで相対URIを使用することで問題はありません。


のような名前付き/ハッシュフラグメントアンカーの使用に関しては、のような<a href="#anchor">クエリ文字列アンカーとのような<a href="?foo=bar">パスフラグメントアンカーを<a href=";foo=bar">使用して、基本的に、それらの種類のアンカーを含む、それに関連するすべての相対リンク<base>を宣言します。相対リンクはいずれも、現在のリクエストURIに相対的ではなくなりました(タグなしで発生する場合のように)。これは、そもそも初心者にとって混乱を招く可能性があります。これらのアンカーを正しい方法で構築するには、基本的にURIを含める必要があります。<base>

<a href="${uri}#anchor">hash fragment</a>
<a href="${uri}?foo=bar">query string</a>
<a href="${uri};foo=bar">path fragment</a>

ここで、${uri}基本的に$_SERVER['REQUEST_URI']はPHP、${pageContext.request.requestURI}JSP、および#{request.requestURI}JSFに変換されます。JSFのようなMVCフレームワークには、この定型文をすべて削減し、の必要性を排除するタグがあることに注意してください<base>他のJSFページへのリンク/ナビゲートに使用するURLも参照してください。

于 2009-12-11T18:24:24.880 に答える
167

ベースタグの効果の内訳:

ベースタグには直感的でない効果があるようです。信頼する前に、結果を認識して自分でテストすることをお勧めします<base>ベースタグを使用して異なるURLのローカルサイトを処理しようとした後にそれらを発見し、問題のある影響を見つけた後、私は残念なことに、他の人のためにこれらの潜在的な落とし穴の要約を作成することを余儀なくされました。

<base href="http://www.example.com/other-subdirectory/">以下の場合の例として、次のベースタグを使用し、コードが存在するページがhttp://localsite.com/original-subdirectoryであると偽ります。

選考科目:

明示的にされていない限り、リンク、名前付きアンカー、または空白のhrefは元のサブディレクトリを指しません。ベースタグは、代わりにベースタグのURLへの同じページのアンカーリンクを含め、 すべてを異なる方法でリンクします。

  • <a href='#top-of-page' title='Some title'>A link to the top of the page via a named anchor</a>
    になります
    <a href='http://www.example.com/other-subdirectory/#top-of-page' title='Some title'>A link to an #named-anchor on the completely different base page</a>

  • <a href='?update=1' title='Some title'>A link to this page</a>
    になります
    <a href='http://www.example.com/other-subdirectory/?update=1' title='Some title'>A link to the base tag's page instead</a>

いくつかの作業で、これらのリンクがそれらが存在するページにリンクすることを明示的に指定することにより、制御できるリンクでこれらの問題を修正できますが、標準の動作に依存するサードパーティのライブラリをミックスに追加すると、それは簡単に大きな混乱を引き起こす可能性があります。

マイナー:

条件付きコメントを必要とするIE6の修正:DOM階層を台無しにしないように、つまり上記の彼の回答で述べたように<base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]-->、ie6に条件付きコメントを必要とします。BalusC

したがって、全体として、すべてのリンクを完全に編集制御できない限り、主要な問題は使用を難しくします。私が最初に恐れていたように、それは価値があるよりも厄介です。今、私は立ち去って、それのすべての使用法を書き直さなければなりません!:p

「フラグメント」/ハッシュを使用する場合の問題のテストに関連するリンク:

http://www.w3.org/People/mimasa/test/base/

http://www.w3.org/People/mimasa/test/base/results


Izzyによる編集:コメントに関して私と同じ混乱に遭遇したすべての人のために:

自分でテストしたところ、次の結果が得られました。

  • 末尾のスラッシュであろうとなかろうと、ここに示した例に違いはありません(#anchorそして?query、指定されたものに単に追加されます<BASE>)。
  • ただし、相対リンクには違いがあります。末尾のスラッシュを省略しother.html、指定された例でdir/other.html開始し、(正しく)ファイルとして扱われるため、省略されます。DOCUMENT_ROOT/other-subdirectory

したがって、相対リンクの場合BASE、移動されたページで正常に機能します。アンカーを?queries使用し、ファイル名を明示的に指定する必要があります(BASE末尾にスラッシュを付けるか、最後の要素が使用されているファイルの名前に対応していません)。

これは、ファイル自体(ファイルが存在するディレクトリではない)への完全なURLを<BASE>置き換えるものと考えてください。そうすれば、問題が解決します。この例で使用されているファイルが(新しい場所に移動された後)であると仮定すると、正しい仕様は次のようになっているはずです。other-subdirectory/test.html

<base href="http://www.example.com/other-subdirectory/test.html">

– et voila、すべて期待どおりに機能します#anchor:、、、、、。?queryother.htmlvery/other.html/completely/other.html

于 2009-12-11T18:14:02.947 に答える
30

さて、ちょっと待ってください。ベースタグがこの悪い評判に値するとは思わない。

ベースタグの良いところは、複雑なURLの書き換えを簡単に行えることです。

これが例です。http://example.com/product/category/thisproducthttp://example.com/product/thisproductに移動することにしました。.htaccessファイルを変更して、最初のURLを2番目のURLに書き換えます。

ベースタグを配置したら、.htaccessの書き換えを行います。これで完了です。問題ない。ただし、ベースタグがないと、すべての相対リンクが壊れます。

URLを微調整すると、サイトのアーキテクチャと検索エンジンの可視性が向上するため、URLの書き換えが必要になることがよくあります。確かに、人々が言及した「#」と「」の問題の回避策が必要になります。ただし、ベースタグはツールキットに含める価値があります。

于 2010-02-16T19:02:17.137 に答える
25

使用するかどうかを決定するには、それが何をするのか、そしてそれが必要かどうかを知っておく必要があります。これは、私も貢献したこの回答ですでに部分的に概説されています。しかし、理解とフォローを容易にするために、ここで2番目の説明をします。まず、次のことを理解する必要があります。

リンクは使用されずにブラウザでどのように処理さ<BASE>れますか?

いくつかの例として、次のURLがあると仮定します。

A)http://www.example.com/index.html
B)http://www.example.com/
C)http://www.example.com/page.html
D)http://www.example.com/subdir/page.html

A + Bはどちらも、まったく同じファイル(index.html)をブラウザに送信し、Cはもちろん、を送信page.htmlし、Dはを送信します/subdir/page.html

さらに、両方のページに一連のリンクが含まれていると仮定します。

1)完全修飾絶対リンク(http://www...
2)ローカル絶対リンク(/some/dir/page.html
3)ファイル名を含む相対リンク(dir/page.html)、および
4)「セグメント」のみの相対リンク(#anchor?foo=bar)。

ブラウザはページを受信し、HTMLをレンダリングします。URLが見つかった場合は、それを指す場所を知る必要があります。リンク1)は、現状のままであるため、これは常に明らかです。他のすべては、レンダリングされたページのURLに依存します。

URL     | Link | Result
--------+------+--------------------------
A,B,C,D |    2 | http://www.example.com/some/dir/page.html
A,B,C   |    3 | http://www.example.com/dir/page.html
D       |    3 | http://www.example.com/subdir/dir/page.html
A       |    4 | http://www.example.com/index.html#anchor
B       |    4 | http://www.example.com/#anchor
C       |    4 | http://www.example.com/page.html#anchor
D       |    4 | http://www.example.com/subdir/page.html#anchor

使用すると 何が変わります<BASE>か?

<BASE>ブラウザに表示されるURLを置き換えることになっています。したがって、ユーザーがで指定されたURLを呼び出したかのようにすべてのリンクをレンダリングします<BASE>。これは、他のいくつかの回答の混乱の一部を説明しています。

  • 繰り返しますが、「完全修飾絶対リンク」(「タイプ1」)の場合は何も変更されません。
  • ローカル絶対リンクの場合、ターゲットサーバーが変更される可能性があります(で指定されたサーバーが<BASE>ユーザーから最初に呼び出されたサーバーと異なる場合)
  • ここでは相対URLが重要になるため、設定方法には特別な注意を払う必要があります<BASE>
    • ディレクトリに設定しない方がよいでしょう。そうすることで、「タイプ3」のリンクは引き続き機能する可能性がありますが、「タイプ4」のリンクは確実に機能しなくなります(「ケースB」を除く)。
    • 完全修飾ファイル名に設定すると、ほとんどの場合、目的の結果が得られます。

例はそれを最もよく説明します

次を使用してURLを「プリティファイ」したいとしますmod_rewrite

  • 実ファイル:<DOCUMENT_ROOT>/some/dir/file.php?lang=en
  • 実際のURL:http://www.example.com/some/dir/file.php?lang=en
  • ユーザーフレンドリーなURL:http://www.example.com/en/file

ユーザーフレンドリーなURLを実際のURLに透過的mod_rewriteに書き換えるために使用されると仮定しましょう(外部リダイレクトがないため、「ユーザーフレンドリー」なURLは、実際のURLが読み込まれている間、ブラウザのアドレスバーに残ります)。今何をする?

  • 指定なし<BASE>:すべての相対リンクを切断します(現在に基づいているためhttp://www.example.com/en/file
  • <BASE HREF='http://www.example.com/some/dir>:絶対に間違っています。指定されたURLのファイルdir部分と見なされるため、それでもすべての相対リンクが壊れています。
  • <BASE HREF='http://www.example.com/some/dir/>:すでに良いです。ただし、「タイプ4」の相対リンクはまだ壊れています(「ケースB」を除く)。
  • <BASE HREF='http://www.example.com/some/dir/file.php>: その通り。すべてがこれで動作するはずです。

最後のメモ

これは、ドキュメント内のすべてのURLに適用されることに注意してください。

  • <A HREF=
  • <IMG SRC=
  • <SCRIPT SRC=
  • …</li>
于 2014-07-09T07:30:15.290 に答える
13

Drupalは当初タグに依存していました<base>が、後でHTTPクローラーとキャッシュの問題のために使用しないという決定を下しました。

私は一般的にリンクを投稿するのは好きではありません。<base>しかし、これは、タグを使用した実際の体験の詳細を探している人に役立つ可能性があるため、共有する価値があります。

http://drupal.org/node/13148

于 2012-08-13T11:39:24.957 に答える
11

ページをオフラインで表示しやすくします。完全修飾URLをベースタグに入れると、リモートリソースが正しく読み込まれます。

于 2009-12-11T16:19:39.890 に答える
5

あまり知られていないので、あまり人気がないかもしれません。すべての主要なブラウザがサポートしているので、私はそれを使用することを恐れません。

サイトでAJAXを使用している場合は、すべてのページでAJAXが正しく設定されていることを確認する必要があります。そうしないと、解決できないリンクが発生する可能性があります。

targetHTML4.01の厳密なページでは属性を使用しないでください。

于 2009-12-11T16:12:13.783 に答える
5

ハッシュ「#」は現在、ベース要素と組み合わせたジャンプリンクで機能しますが、IE9ではなく最新バージョンのGoogleChromeとFirefoxでのみ機能します。

IE9は、どこにもジャンプせずにページをリロードするように見えます。iframeの外側でジャンプリンクを使用している場合、フレーム内の別のページにジャンプリンクを読み込むようにフレームに指示すると、代わりにフレーム内に読み込まれたジャンプリンクページの2番目のコピーが取得されます。

于 2012-03-16T07:53:54.297 に答える
3

ページにインライン化されたSVG画像の場合、baseタグを使用すると発生する別の重要な問題があります。

タグを使用するbaseと(すでに前述したように)、次のように相対ハッシュURLを使用する機能が事実上失われます。

<a href="#foo">

これは、現在のドキュメントの場所ではなくベースURLに対して解決されるため、相対的ではなくなるためです。したがって、現在のドキュメントのパスを次のような種類のリンクに追加する必要があります。

<a href="/path/to/this/page/name.html#foo">

したがって、タグの一見ポジティブな側面の1つbase(長いURLプレフィックスをアンカータグから遠ざけて、より適切で短いアンカーを取得すること)は、ローカルハッシュURLに対して完全に裏目に出ます。

これは、静的SVGであれ動的に生成されたSVGであれ、ページにSVGをインライン化するときに特に厄介です。これは、SVGにはそのような参照が多数存在する可能性がありbase、タグが使用されるとすぐにすべてが壊れてしまうためです。エージェントの実装(Chromeは、執筆時点では少なくともこれらのシナリオで機能します)。

ページを処理/生成するテンプレートシステムまたは別のツールチェーンを使用している場合、私は常にタグを削除しようとします。baseこれは、私が見ているように、解決するよりも多くの問題をテーブルにもたらすためです。

于 2017-01-25T08:38:07.963 に答える
3

また、非標準ポートでWebサーバーを実行している場合は、ベースhrefにもポート番号を含める必要があることを覚えておく必要があります。

<base href="//localhost:1234" />  // from base url
<base href="../" />  // for one step above
于 2017-05-10T05:48:43.887 に答える
2

私はそれを使用することの意味を実際に見たことがありません。利点はほとんどなく、使いにくくなる可能性もあります。

数百または数千のリンクがない限り、すべて同じサブディレクトリにあります。次に、帯域幅を数バイト節約できる可能性があります。

後付けとして、IE6のタグに問題があったことを思い出しているようです。それらを体のどこにでも配置して、サイトのさまざまな部分をさまざまな場所にリダイレクトすることができます。これは、多くのサイトを壊したIE7で修正されました。

于 2009-12-11T16:14:45.573 に答える
2

覚えておくべき1つのこと:

iOSのUIWebView内に表示されるWebページを開発する場合は、BASEタグを使用する必要があります。それ以外の場合は機能しません。JavaScript、CSS、画像など、タグBASEが指定されていない限り、UIWebViewの相対リンクでは機能しません。

私はそれを知るまで、これに捕らえられたことがあります。

于 2012-10-18T15:24:44.983 に答える
2

base-tagが使用されているサイトもあり、説明されている問題が発生しました。(jqueryをアップグレードした後)、次のようなタブURLを持つことで修正できました:

<li><a href="{$smarty.server.REQUEST_URI}#tab_1"></li>

これにより、それらは「ローカル」になります

私が使用した参照:

http://bugs.jqueryui.com/ticket/7822 http://htmlhelp.com/reference/html40/head/base.html http://tjvantoll.com/2013/02/17/using-jquery-ui- tabs-with-the-base-tag /

于 2013-03-28T10:29:01.050 に答える
2

AngularJSを使用すると、BASEタグが$ cookieStoreを黙って壊し、アプリがCookieを書き込めなくなった理由を理解するのに時間がかかりました。警告してください...

于 2017-04-20T08:46:49.573 に答える
1

<base>ベースのリンクを使用してアンカーする方法を見つけました。JavaScriptを使用して、リンクを必要に応じて機能させることができます#contact。私はいくつかの視差ページでそれを使用しました、そしてそれは私のために働きます。

<base href="http://www.mywebsite.com/templates/"><!--[if lte IE 6]></base><![endif]-->

...content...

<script>
var link='',pathname = window.location.href;
$('a').each(function(){
    link = $(this).attr('href');
    if(link[0]=="#"){
        $(this).attr('href', pathname + link);
    }
});
</script>

ページの最後に使用する必要があります

于 2016-10-19T05:14:02.927 に答える
1

ベースhrefの例

リンク付きの典型的なページを言います。

<a href=home>home</a> <a href=faq>faq</a> <a href=etc>etc</a>

。そしてdiffフォルダへのリンク:

..<a href=../p2/home>Portal2home</a> <a href=../p2/faq>p2faq</a> <a href=../p2/etc>p2etc</a>..

base hrefを使用すると、baseフォルダーの繰り返しを回避できます。

<base href=../p2/>
<a href=home>Portal2-Home</a> <a href=faq>P2FAQ</a> <a href=contact>P2Contact</a>

つまり、それは勝利です。それでもページには、ベースを比較するためのURLが含まれていることがよくあります。現在のWebは、ページごとに1つのベースhrefしかサポートしていないため、base∙hrefedではないベースが繰り返されると、勝利はすぐに失われます。

<a href=../p1/home>home</a> <a href=../p1/faq>faq</a> <a href=../p1/etc>etc</a>
<!--.. <../p1/> basepath is repeated -->

<base href=../p2>
<a href=home>Portal2-Home</a> <a href=faq>P2FAQ</a> <a href=contact>P2Contact</a>


結論

ベースターゲットが役立つ場合があります。)ベースhrefは次のように役に立ちません。

  • 次の理由から、 ページも同様にウェットです。
    • デフォルトのベース[–親フォルダー]⇌完全(不要/まれな例外を除く
于 2017-10-03T07:24:15.350 に答える
1

URLパスの管理にこの要素を使用しないことを<base>お勧めします。なんで?

ある問題を別の問題と交換するだけです。基本要素がないと、相対パスとリンクが壊れることを恐れずに、任意のパスシステムを使用できます。ベース要素をパスに設定した瞬間に、そのパスで機​​能するようにすべてのURLを設計するために「ロックイン」され、ベースパスから機能するようにすべてのパスを変更する必要があります。悪いアイデア!

つまり、より長いパスを記述し、各パスがこのベースに対してどこにあるかを追跡する必要があります。さらに悪いことに、<base>要素を使用する場合は、完全修飾ベースパスを使用して古いブラウザ( " https://www.example.com/ ")をサポートすることをお勧めします。これで、ドメインをにハードコーディングしました。ページまたはすべてのリンクを有効なドメインパスに依存させました。

一方、ウェブサイトからベースパスを再度削除すると、完全修飾可能な短い相対パスを使用したり、ルートからの絶対パスを使用したり、真に相対的なパスを使用したりできるようになります。あなたがいるファイルとフォルダ。そのはるかに柔軟性があります。そして、「#hello」のようなすべてのフラグメントのベストは、追加の修正なしで正しく機能します。繰り返しますが、人々は存在しない問題を生み出しています。

また、Webページのフォルダを新しいサブフォルダの場所に移行するためにベースURLを使用するという上記の議論は、今日では実際には重要ではありません。ほとんどの最新のサーバーでは、任意のドメインの下で新しいアプリケーションルートフォルダとして任意のサブフォルダをすばやく設定できるからです。Webアプリケーションの定義または「ルート」は、現在、フォルダーまたはドメインのいずれによっても制約されていません。

この議論全体はちょっとばかげているようです。したがって、ベースURLを省略し、それを使用しない古いネイティブサーバークライアントのデフォルトパスシステムをサポートすると言います。

注:新しいAPIシステムが原因でパスを制御することが問題である場合、解決策は簡単です...API内のすべてのURLとリンクをパスする方法に一貫性を持たせてください。ベースやHTML5のブラウザサポート、またはjavascriptAPIキディのような新しいサーカストリックに依存しないでください。すべてのアンカータグを一貫してパスするだけで、問題が発生することはありません。さらに、使用するパスシステムに関係なく、Webアプリケーションを新しいサーバーに即座に移植できます。

古いものはまた新しいです!基本的な要素は明らかに、20年前、ましてや今日ではWebWorldには存在しなかった問題の解決策を作成しようとすることです。

于 2020-03-23T06:09:00.077 に答える
0

タグを設定してはいけない理由の長いリストにもう1つの引数を追加します。<base href>他の多くの人がここで指摘しているように、設定<base href>により#anchorおよび?query URLの動作が変更されます。これらは、ドキュメント自体のURLであるフォールバックベースではなく、ベースhrefにアタッチされます。

<base href="https://example.com/the/documents/own/url">設定によってこれが解決し、すべてが正常に動作すると思うかもしれません。あなたは間違っているでしょう。

実際のWebでは、?query = parametersは、セッションのアトリビューション(Google Analyticsの場合と同様)やその他の多くの目的で常に使用されます。これらのパラメーターの多くは、スクリプトによるクライアント側での使用専用です。サーバーはそれらを気にせず、何もしません。

、、およびページ上のへのリンクを使用してサービスを提供example.com/landing-pageしているとします。次に、誰かがURLを介してそこに到着します。<base href="example.com/landing-page">#menuexample.com/landing-page?source=my-marketing-campaign

がないと<base href>、#menuをクリックすると、ブラウザはページ内ナビゲーションを認識し、すぐにそのセクションにジャンプします。

ただし、定義したベースhrefexample.com/landing-pageにクエリパラメータがないためsource=my-marketing-campaign、ブラウザはそれがページ内リンクであることを確認できません。したがって、#menuをクリックすると、新しいHTTPリクエストが発生し、ページ(およびそのすべてのキャッシュされていないアセット)がリロードされます。最良のシナリオでは、これはすべての面で時間と帯域幅の無意味な浪費です。最悪の場合、状態とデータが失われる可能性があります。

静的サイトの場合、これを回避する方法はありません。<base href>CMSを使用している場合は、すべてのパラメーターが含まれているリクエストURLに動的に設定できると少し考えられるかもしれません。これで更新の問題は解決しますが、キャッシュの問題と悪夢を引き起こすセキュリティの脆弱性が発生することになります。

結論:<base href>何を設定しても、問題が発生します。しないでください。

悪意のあるスクリプトが独自のタグを挿入する可能性が懸念される場合<base href="evil.com">(たとえば、ナンスのリターゲティング攻撃)、2022年の最善の解決策は、コンテンツセキュリティポリシーにbase-uriディレクティブを追加することです。

于 2022-02-26T14:36:22.837 に答える