allowsEnvRootKey
allowsEnvRootKey(
host?):boolean
Defined in: core/src/utils/helper.ts:220
Whether the configuration carried by the ic_env cookie may be trusted for a
host: its root key, its Internet Identity provider, and the canister IDs a
reactor resolves by name.
This is a POSITIVE allowlist, and deliberately not !isMainnetHost(host).
isMainnetHost recognises exactly three mainnet domains, so every other host
— including a production dapp served from an ic-domains custom domain —
fell through it and accepted a root key supplied by a cookie. Cookies are not
origin-isolated, so any sibling subdomain of the registrable domain could
substitute the key that certificate verification is checked against.
The same reasoning covers the canister ID a Reactor resolves when none is
configured: a substituted ID is not something certificate verification can
catch, because the attacker names a real canister whose responses verify
against the real root key.
Accepted: loopback and localhost and its subdomains. Everything else must
opt in explicitly through allowEnvConfig, including the Codespaces and
Gitpod domains that forward a local replica (network "remote"). Every
user of those platforms gets a subdomain of the same parent, which is not a
public suffix, so a page in a stranger’s workspace can set ic_env for
yours. They used to be accepted.
This answers the question for ONE host. ClientManager asks it of both the
agent host and the page origin — the page being what decides who can write
the cookie — and resolves the pair once into trustsEnvConfig. Prefer
reading that over calling this again, so every consumer of the cookie
agrees.
Parameters
Section titled “Parameters”string
The host URL to evaluate.
Returns
Section titled “Returns”boolean
true only for hosts that are unambiguously a local replica.