APP_NAME is a runtime variable and two of the three places showing the name ignored it. The sign-in page fetched /api/config, received the name and used only sourceUrl -- so a rebranded deployment still said "ihasmail" on the one page a new user meets first. The top bar had it written in. Only the document title read it, and it had been reading it from the session all along. The rebranding guide documents both as things to patch yourself, one of them with "if you change nothing else on this page, change this". It should not have to. The sign-in page takes the name from the answer it was already getting. The top bar takes it from the session, where the title has taken it from since it was written. Neither is a new request. One shared default rather than the string written out at three call sites, because three copies of a default is how two of them end up stale. It stands if the config request fails, since a sign-in form with no name on it would be worse than one with the wrong name -- and an empty or non-string name falls back too, so a deployment that sets APP_NAME= does not get a nameless page. Confirmed with APP_NAME set to something else: sign-in heading, top bar and tab title all read it.
14 lines
613 B
TypeScript
14 lines
613 B
TypeScript
/**
|
|
* What this instance calls itself, when nothing has said otherwise yet.
|
|
*
|
|
* `APP_NAME` is a runtime environment variable, so the real answer arrives
|
|
* from the server -- on `/api/config` before anybody signs in, and on the
|
|
* session afterwards. This is what stands in until it does, and what stands
|
|
* for good if the request fails: a sign-in form with no name on it would be
|
|
* worse than one with the wrong name.
|
|
*
|
|
* One constant rather than the string written out at each of them, because
|
|
* three copies of a default is how two of them end up stale.
|
|
*/
|
|
export const DEFAULT_APP_NAME = "ihasmail";
|