[18] challenge の realm 引数は、
HTTP認証が適用される範囲を表す短い文字列です。
認証方式によっては credentials でも使います。
[37] 保護空間は、
アクセスされている鯖の正準根URLと、指定されていれば
realm の値とにより決まります >>36。
[16] realm は、鯖をいくつかの保護空間に分割するものです
>>36, >>11, >>21, >>28。
[29] realm 引数は、保護の範囲を示す必要がある認証方式で使うために予約されています
>>36, >>45。新しい認証方式はこれと非互換な方法で使ってはなりません
>>45。
[17] realm は、通常起源鯖によって割り当てられる文字列であり、
auth-scheme によっては更に何らかの意味を与えているかもしれません。
>>36, >>11, >>21, >>28
[12] 要求が認証された場合であって、 realm が指定されていた場合にあっては、 同じ credentials が同一の realm を共有するすべての要求に対しても妥当であるべきです。 >>11, >>22, >>24
[19] しばしば、「パスワードを入力してください」のような利用者に対するメッセージを含める場所として使われます。 入力するべきパスワードの種別を示した短い説明文や、 (機械的なアクセスを拒みたいなどの理由でパスワードを設定する場合に) パスワードそのものが記述されていることもあります。
[41] auth-param の値は一般には字句か引用文字列とされていますが、
歴史的理由により、送信者は引用文字列として生成しなければなりません
>>36, >>53。しかし受信者は字句も対応しないといけないかもしれません >>36。
[42] 値としては (引用文字列として表現できる) 任意の文字の列が認められているようです。
[3] >>1 によると空文字列も特に制限されていないみたいですね。
[15] realm 引数の値は大文字・小文字を区別します >>11, >>21, >>28。
[20] RFC 上は認められていませんが、シフトJISやUTF-8など任意のcharset
による非ASCII文字が含まれることがよくあります。その場合、
Content-Type: ヘッダーの charset
引数があったとしても、それと一致しているとは限りません。
auth-param も参照。[13] realm 引数は challenge で指定します。
realm-param
よりも前に1つだけ指定する構文になっていましたが、RFC 2617 では特にそういう制限はなくなっています。
(元から制限する意図が無かったのでしょう。)[56] Digest 認証では、 challenge の他 credentials
でも使います >>53。
[54] ダイジェスト認証では、 realm は、
利用者が指定するべき利用者名と合言葉を知るために表示される文字列です
>>53。少なくても認証を行うホストの名前は含んでいるべきで、
それに加えて利用者がアクセスできるであろう集成をも示すことができます >>53。
challenge でも credentials でも使います >>53。
[55] 例えば registered_users@example.com のような値を指定できます >>53, >>26。
[27] realm 引数の値はダイジェスト値の計算に使われます。
非ASCII文字が含まれる場合の扱いは定かではありません。
[57] ダイジェスト値の計算に realm が含まれているので、
サーバー内で生の合言葉を保存せずにダイジェスト値だけを保管している場合で、
それが仮に流出したとしても、生の合言葉は簡単にはわからない (と期待される)
ので、他の realm にその値を流用するのが難しくなります >>35。
[59] realm は、特定の利用者が使い得る他のどんな
realm とも異なるものとするべきです。
そのために認証を行うホストの名前を含めるべきです。 >>35
[33] OAuth 1.0 は realm 引数を追加して構わないとしています
>>30。逆に言えば省略しても構わないということで、 >>14 と矛盾していました。
[10] OAuth 1.0 だと realm は意味が無いのですが、指定することは認められています。
特に意味が無いので空文字列が指定されたりすることもあります。
[34] OAuth 1.0 では realm を省略することができますが、
Apple のライブラリー NSURLProtectionSpace を使っている Safari や iOS
アプリケーションは realm が存在しないとクラッシュします。
[48] OAuth 2.0 Bearer は RFC 2617 を参照して
realm の使用を認めています >>47。
実際には意味はなさそうです。
[39] 保護空間によって credentials が自動的に適用できる範囲が決まります。
利用者エージェントは、以前の要求が認可されている場合には、
その credentials を保護空間内の他の要求にも (auth-scheme や
auth-param や利用者の設定で決まる期間中は)
再利用して構いません。 >>36
[43] 基本認証やダイジェスト認証では、利用者の名前と合言葉の入力を促す画面に
realm の値も示す実装が普通です。鯖側でも、
利用者に表示されることを前提とした人間可読なメッセージを
(当該資源において相応しいと思われる言語で) 記述するのが一般的です。
[64]
ロボットアクセス拒否を目的に?基本認証を使っていて、
realm に credentials が書いてあるサイトもあるのですが、
Chrome ではそのことがわかりません。
realm = "realm" "=" realm-value realm-value = quoted-stringThe realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realms.
[4] HTTP/1.1 WWW-Authenticate header ( 版) http://www.http-stats.com/WWW-Authenticate
WWW-Authenticate: Basic realm=""
WWW-Authenticate: Basic
WWW-Authenticate: Basic realm = "You need ID",
WWW-Authenticate: Basic realm= /
WWW-Authenticate: Basic realm=BSI SkimmerPlus Server 1.0.0.20 / 1.0.0.30
[60] RFC 7804 - Salted Challenge Response HTTP Authentication Mechanism ( 版) https://tools.ietf.org/html/rfc7804#section-5
[61] RFC 8053 - HTTP Authentication Extensions for Interactive Clients () https://tools.ietf.org/html/rfc8053#section-4.1
[62] RFC 8120 - Mutual Authentication Protocol for HTTP () https://tools.ietf.org/html/rfc8120#section-3.1