`DRFED_LOGIN_ORIGINS` does not normalize a trailing dot

[dahlia]

DRFED_LOGIN_ORIGINS is parsed in packages/drfed/src/index.ts with new URL(value).origin, and expandVerifyUrl() in packages/graphql/src/auth/expand.ts checks membership with loginOrigins.has(url.origin).

For HTTP and HTTPS URLs, URL.origin lowercases the scheme and the host and omits the path and query, but it preserves a trailing dot in the host name. So this:

DRFED_LOGIN_ORIGINS=https://app.example.

stores https://app.example. in the set. A browser on https://app.example reports globalThis.location.origin without the dot, the membership check never matches, and login attempts from that origin fail with:

Verify URL origin is not allowed: https://app.example.

That message reports the origin the browser sent, not the one that was configured, and its sentence-ending period sits exactly where the configured value's trailing dot would be. Both spellings look identical in the error.

The current work for #77 adds trailing-dot normalization to the origin() value parser in packages/drfed/src/valueparser.ts, for the same reason on a different knob. That parser could be reused here: parse each configured value with origin({ allowedProtocols: ["http:", "https:"] }) and store the returned URL's origin, treating a parse failure as a configuration error. Note that allowIpLiterals: false should not be carried over from the --root-origin configuration, since a login origin may legitimately be an IP address.

A separate question, if anyone wants to settle it here: should login origins be configurable through a CLI option rather than an environment variable?

[dodok8]

I think using enviroemnt variable gives choice to users, like ENV=12321312 <command> or <command>(default fallback to .env file.)