URL/URIのハッシュタグ「#」
search cancel

URL/URIのハッシュタグ「#」

book

Article ID: 276313

calendar_today

Updated On:

Products

SITEMINDER

Issue/Introduction

URL/URI に「#」文字が含まれている場合、CA Single Sign-On (SiteMinder) はこの URL/URI を処理できません。

「#」が含まれる場合、URL は切り詰められます。これは Access Gateway (SPS) も同様な結果となります。

CA Single Sign On (SiteMinder) は URL/URI 内の # をどのように処理しますか?

これは CA Single Sign-On の問題ですか、それともエージェントまたは Access Gateway の問題ですか?

Cause

1. ユーザーは Web サーバーにリクエストを送信する際に %23 (「#」) を送信する必要があります。一部のブラウザーは、「#」が存在する場合でも完全な URL を送信します。その場合、問題は発生しません。

2. %23 (「#」) がリクエストの一部として送信されても、認証後に最終ページが切り捨てられます。(これは R12.52 SP1 CR9 で修正されました。)

3. ブラウザが URL を切り詰めている場合、Web Agent / Access Gateway はそれを修正できません。

Resolution

「#」文字は安全でない文字とみなされます。

RFC1738の「unsafe」文字の詳細:
https://www.ietf.org/rfc/rfc1738.txt

すべての安全でない文字は、常に URL 内でエンコードする必要があります。たとえば、文字「#」は、フラグメント識別子やアンカー識別子を通常は扱わないシステムであっても、URL 内でエンコードする必要があります。これにより、URL がそれらを使用する別のシステムにコピーされた場合に、URLエンコードを変更する必要がなくなります。

URL の最初のハッシュ記号の後に表示される情報はフラグメント識別子と呼ばれ、アンカー タグとも呼ばれます。デフォルトでは、フラグメント識別子はローカル Web ブラウザによってのみ解釈され、通常はリモート Web サーバーには渡されません。たとえば、次の 2 つのリンクは両方とも、Web サーバーによって同じドキュメントに対するリクエストとみなされます。

www.example.com/fruits.html#apple
www.example.com/fruits.html#orange

これは URI 構文の問題である可能性があります。「#」は URL の終わりの記号と見なされるため、これを URL の一部として配置すると、単に終了文字とみなされ、理解されません。

したがって、上記の例では、上記の URL にアクセスすると、Web ブラウザはそれを切り捨てて、以下のように Web サーバーに送信します。

www.example.com/fruits.html
www.example.com/fruits.html

したがって、リクエストがリソース自体に「#」を含まない Web エージェントに送信される場合、エージェントはここでリクエストを変更したり切り捨てたりしません。

以上より、URL が切り詰められる問題は Web エージェントによるものではなく、Web ブラウザ (URI 構文) 自体がこれを URL の終わりと見なし、「#」以後を無視することによります。

Additional Information

URI 構文の詳細については、以下のリンクを参照してください。
https://tools.ietf.org/html/rfc3986 

[英語文書] Hashtag "#" in URL / URI