dtoro
d4d99a7473
Problem: the hexagonal refactor churns the backend tree for nine more phases; the UI delivery stack (web/ SPA, cmd/desktop Wails wrapper, compose/web image) must move to its own repo first so doc/layout rewrites land once on a backend-only tree. Change: - New repo git.hubris.network/dtoro/oikos-web (v0.33.0): web/, desktop/ (updateURL repointed to oikos-web releases), compose/, own CI (web + desktop jobs), own deploy script (CI-green gate, TOCTOU guard, version-tagged images, prune-to-3), own webhook receiver on :9798 + launchd unit, own compose project publishing the same 8091:80. - Cutover executed on mac-mini in order: oikos stack's web service stopped+removed, oikos-web project brought up on 8091; outer Caddy untouched (targets the published port) — serving + Authentik flow + /wails 404 quirk verified post-cutover. - Stripped from oikos: web/, cmd/desktop/, compose/web/, desktop CI workflow, ci.yml web job, Makefile ui/desktop/desktop-package/install targets, the compose web service, oikos-web from deploy.sh's fallback prune list; wails + go-keyring dropped from go.mod, vendor synced. - README / CONTRIBUTING / AGENTS.md / .agents dev+operations docs now point at the new repo; mbse + mascot design docs carry a path note. Risk: production SPA serving depends on the new pipeline now; rollback is versioned-image re-up of the old web service from a pre-split checkout (port 8091). Desktop builds installed before the split still check dtoro/oikos releases — one manual reinstall, noted in the oikos-web release notes. Verification: go vet, make test (race), make generate-check, golangci (no new findings; baseline down 400→365); post-cutover curls — localhost:8091 200, /wails/runtime.js 404, outer Caddy 302 Authentik.
39 lines
1.5 KiB
TypeScript
39 lines
1.5 KiB
TypeScript
import type { Nullable } from '../utils';
|
|
/**
|
|
* Answers "does this real domain match the domain in a cookie?". The `domain` is the "current" domain name and the
|
|
* `cookieDomain` is the "cookie" domain name. Matches according to {@link https://www.rfc-editor.org/rfc/rfc6265.html#section-5.1.3 | RFC6265 - Section 5.1.3},
|
|
* but it helps to think of it as a "suffix match".
|
|
*
|
|
* @remarks
|
|
* ### 5.1.3. Domain Matching
|
|
*
|
|
* A string domain-matches a given domain string if at least one of the
|
|
* following conditions hold:
|
|
*
|
|
* - The domain string and the string are identical. (Note that both
|
|
* the domain string and the string will have been canonicalized to
|
|
* lower case at this point.)
|
|
*
|
|
* - All of the following conditions hold:
|
|
*
|
|
* - The domain string is a suffix of the string.
|
|
*
|
|
* - The last character of the string that is not included in the
|
|
* domain string is a %x2E (".") character.
|
|
*
|
|
* - The string is a host name (i.e., not an IP address).
|
|
*
|
|
* @example
|
|
* ```
|
|
* domainMatch('example.com', 'example.com') === true
|
|
* domainMatch('eXaMpLe.cOm', 'ExAmPlE.CoM') === true
|
|
* domainMatch('no.ca', 'yes.ca') === false
|
|
* ```
|
|
*
|
|
* @param domain - The domain string to test
|
|
* @param cookieDomain - The cookie domain string to match against
|
|
* @param canonicalize - The canonicalize parameter toggles whether the domain parameters get normalized with canonicalDomain or not
|
|
* @public
|
|
*/
|
|
export declare function domainMatch(domain?: Nullable<string>, cookieDomain?: Nullable<string>, canonicalize?: boolean): boolean | undefined;
|