Follow-up to #191, which made the Basic realm default to the system's SMF ID (MVSC on the reference system) instead of the constant "MVS". Two remaining pieces, filed together because they are one decision, not two.
The decision
Does the server have a configured, human-readable name — and where does it appear?
Splitting these would mean the login-page half cannot be decided without knowing the answer to the first half, since without a configured name the page would simply show the SMF ID. One issue, two parts.
Part 1 — a Parmlib override for the realm
MVSC identifies the system unambiguously but says nothing to a user. REALM MVS Development System would.
- Keyword
REALM <string> in the Parmlib, defaulting to the httprlm() result.
- A field in the HTTPD block (several
unused_* slots are free), a D CONFIG line, docs/configuration.md, docs/messages.md.
Speculative until someone runs an AUTH=BASIC route. After #121 the realm is only emitted on AUTH=BASIC routes and on inherited routes falling through to Basic — AUTH=TOKEN never sends a challenge — and the sample Parmlib currently marks no route BASIC. Worth building when a deployment needs it, not before.
Part 2 — the login form names no system
httpcred.c titles the page "Login Required". If the server acquires a name, a user meets two different identities depending on which challenge they get: the browser dialog says MVSC (or the configured name), the form says nothing at all.
Options, in increasing order of ambition:
- Leave it — the realm is an HTTP-protocol concept and the form is a different mechanism.
- Put the name in the form: "Login Required — MVSC". One line, removes the inconsistency, introduces no new concept.
- Introduce a general "server name" that feeds both, of which the realm is one use.
Suggested: 2, unless part 1 grows into something that wants 3.
Not in scope
Per-route REALM=. Distinct realms give the browser distinct credential caches — httpd's own store keys on (address, userid, password) and would not change — so the benefit is real but narrow: keeping an admin area's credentials from being sent automatically to the rest of the site. Easy to add later, hard to withdraw once someone relies on the separate caches.
Follow-up to #191, which made the Basic realm default to the system's SMF ID (
MVSCon the reference system) instead of the constant"MVS". Two remaining pieces, filed together because they are one decision, not two.The decision
Does the server have a configured, human-readable name — and where does it appear?
Splitting these would mean the login-page half cannot be decided without knowing the answer to the first half, since without a configured name the page would simply show the SMF ID. One issue, two parts.
Part 1 — a Parmlib override for the realm
MVSCidentifies the system unambiguously but says nothing to a user.REALM MVS Development Systemwould.REALM <string>in the Parmlib, defaulting to thehttprlm()result.unused_*slots are free), aD CONFIGline,docs/configuration.md,docs/messages.md.Speculative until someone runs an
AUTH=BASICroute. After #121 the realm is only emitted onAUTH=BASICroutes and on inherited routes falling through to Basic —AUTH=TOKENnever sends a challenge — and the sample Parmlib currently marks no routeBASIC. Worth building when a deployment needs it, not before.Part 2 — the login form names no system
httpcred.ctitles the page "Login Required". If the server acquires a name, a user meets two different identities depending on which challenge they get: the browser dialog saysMVSC(or the configured name), the form says nothing at all.Options, in increasing order of ambition:
Suggested: 2, unless part 1 grows into something that wants 3.
Not in scope
Per-route
REALM=. Distinct realms give the browser distinct credential caches — httpd's own store keys on (address, userid, password) and would not change — so the benefit is real but narrow: keeping an admin area's credentials from being sent automatically to the rest of the site. Easy to add later, hard to withdraw once someone relies on the separate caches.