m/paliad
1
0
Fork 0
Code Issues 151 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Decide which firm domain is canonical — accounts exist on hoganlovells.com while the live domain is hlc.com, and three products key off the pair #159

New Issue
Open
opened 2026-07-27 10:04:42 +00:00 by mAi · 1 comment
mAi commented 2026-07-27 10:04:42 +00:00
Collaborator
Copy Link

Surfaced 2026-07-27 while checking whether a user (Cedric Rohr) had a Paliad account. He does — cedric.rohr@hoganlovells.com, created 2026-04-26. That resolved his question, but it exposed a risk nobody owns.

The problem

Since the merger the firm is Hogan Lovells Cadwalader and hoganlovells.com 301-redirects to hlc.com (verified directly — fetching https://www.hoganlovells.com/de/legal-notices/disclaimer lands on www.hlc.com/...).

Paliad's ALLOWED_EMAIL_DOMAINS allowlists both forms (hoganlovells.com,hlc.com,hlc.de). So a colleague can sign up under either, and paliad has no merge story for the two identities. Concretely:

  • A user with an existing @hoganlovells.com account who later signs up as @hlc.com gets a second, empty account — same human, no projects, no deadlines, no team memberships. From their side the product simply looks broken.
  • Nothing detects or reconciles this. There is no linking, no alias, no admin merge path.
  • otto reports the reverse is already happening in practice on other contacts: for Michael Plagge and Leonard Hollander the addresses actually in use are on hlc.com, while the hoganlovells.com form is the stale one. So both directions are live.

Today there is exactly one user per human and no duplicates (checked). This is a latent problem, not a current outage — but it becomes real the first time someone signs up with the other form.

Why this is not a paliad-local decision

The same domain pair is load-bearing in at least three products:

  • paliad — ALLOWED_EMAIL_DOMAINS gate, 51 users today, all on hoganlovells.com.
  • m/hihlc — issues #11 and #7 cover an HL-email gate on hihlc.de allowlisting both hlc.com and hoganlovells.com, reusing the youpc accounts.
  • youpc — the account substrate hihlc reuses.

If each product decides independently which form is canonical, they drift apart, and a user's identity depends on which product they signed into first. That is a worse failure than any single product getting it wrong consistently.

What needs deciding

  1. Which form is canonical — hlc.com (the live domain) or hoganlovells.com (where the existing accounts are)? These pull in opposite directions: the live domain is the future, the existing accounts are the present.
  2. What happens to accounts on the non-canonical form. Migrate them, alias them, or keep accepting both and add identity linking.
  3. Whether signup should refuse the non-canonical form once decided, so the problem stops growing.
  4. Who owns the decision across the three products — this is the part that makes it an issue rather than a paliad ticket.

Suggested shape, not a decision

Accepting both at the gate but normalising to one canonical form at account creation would stop new duplicates without locking anyone out mid-transition, and is reversible. That is a guess, not a recommendation — the cross-product owner should decide before anyone builds.

Not urgent

No current duplicate accounts. Filing it because it is exactly the class of finding that dissolves when a chat scrolls, and it bites silently — the symptom is a colleague seeing an empty product and concluding the tool does not work, not an error anyone gets paged about.

Filed by paliad/head at otto/head's request. Cross-references: otto message 5652; m/hihlc#11, m/hihlc#7.

Surfaced 2026-07-27 while checking whether a user (Cedric Rohr) had a Paliad account. He does — `cedric.rohr@hoganlovells.com`, created 2026-04-26. That resolved his question, but it exposed a risk nobody owns. ## The problem Since the merger the firm is Hogan Lovells Cadwalader and **`hoganlovells.com` 301-redirects to `hlc.com`** (verified directly — fetching `https://www.hoganlovells.com/de/legal-notices/disclaimer` lands on `www.hlc.com/...`). Paliad's `ALLOWED_EMAIL_DOMAINS` allowlists **both** forms (`hoganlovells.com,hlc.com,hlc.de`). So a colleague can sign up under either, and paliad has **no merge story** for the two identities. Concretely: - A user with an existing `@hoganlovells.com` account who later signs up as `@hlc.com` gets a **second, empty account** — same human, no projects, no deadlines, no team memberships. From their side the product simply looks broken. - Nothing detects or reconciles this. There is no linking, no alias, no admin merge path. - otto reports the *reverse* is already happening in practice on other contacts: for Michael Plagge and Leonard Hollander the addresses actually in use are on `hlc.com`, while the `hoganlovells.com` form is the stale one. So both directions are live. Today there is exactly one user per human and no duplicates (checked). This is a latent problem, not a current outage — but it becomes real the first time someone signs up with the other form. ## Why this is not a paliad-local decision The same domain pair is load-bearing in at least three products: - **paliad** — `ALLOWED_EMAIL_DOMAINS` gate, 51 users today, all on `hoganlovells.com`. - **m/hihlc** — issues #11 and #7 cover an HL-email gate on hihlc.de allowlisting **both** `hlc.com` and `hoganlovells.com`, reusing the youpc accounts. - **youpc** — the account substrate hihlc reuses. If each product decides independently which form is canonical, they drift apart, and a user's identity depends on which product they signed into first. That is a worse failure than any single product getting it wrong consistently. ## What needs deciding 1. **Which form is canonical** — `hlc.com` (the live domain) or `hoganlovells.com` (where the existing accounts are)? These pull in opposite directions: the live domain is the future, the existing accounts are the present. 2. **What happens to accounts on the non-canonical form.** Migrate them, alias them, or keep accepting both and add identity linking. 3. **Whether signup should refuse the non-canonical form** once decided, so the problem stops growing. 4. **Who owns the decision across the three products** — this is the part that makes it an issue rather than a paliad ticket. ## Suggested shape, not a decision Accepting both at the gate but **normalising to one canonical form at account creation** would stop new duplicates without locking anyone out mid-transition, and is reversible. That is a guess, not a recommendation — the cross-product owner should decide before anyone builds. ## Not urgent No current duplicate accounts. Filing it because it is exactly the class of finding that dissolves when a chat scrolls, and it bites silently — the symptom is a colleague seeing an empty product and concluding the tool does not work, not an error anyone gets paged about. *Filed by paliad/head at otto/head's request. Cross-references: otto message 5652; m/hihlc#11, m/hihlc#7.*
mAi commented 2026-07-29 14:37:20 +00:00
Author
Collaborator
Copy Link

Three of the four items are done. The fourth is the cross-product one and I cannot answer it from paliad.

What I ran — read-only queries against prod, plus the auth and internal/emaildomain code paths. Going through the issue's own list rather than assuming m's ruling settled all of it.

1. Which form is canonical — DONE

m ruled 2026-07-27: hlc.com canonical, hoganlovells.com alias, hlc.de dropped. internal/emaildomain carries the split.

2. What happens to accounts on the non-canonical form — DONE, and the migration has already run

The issue records "51 users today, all on hoganlovells.com". That is no longer the state. On prod now:

domain auth.users
hlc.com 60
hoganlovells.com 0

And the reconciliation is clean:

  • paliad.users on hoganlovells.com: 0; on hlc.com: 47
  • paliad.users ↔ auth.users email mirror drift: 0
  • humans holding both forms: 0

The accounts were renamed rather than duplicated, and cmd/canonicalize-emails is the machinery that did it. The concrete risk the issue was filed about — "a second, empty account… same human, no projects" — has zero instances.

Sign-in still accepts the alias and says so rather than failing: handleAPILogin returns a notice telling the user their address moved to @hlc.com and that the old one keeps working.

3. Whether signup should refuse the non-canonical form — DONE

This is the item that would have let the problem regrow, so it is worth spelling out. There are two gates, deliberately different:

  • isAllowedEmailDomain — sign-IN, still accepts hoganlovells.com, so no existing holder is locked out.
  • isCreatableEmailDomain — every path that mints a new identity (register, both admin-create paths, invitation recipients). It filters AllowedEmailDomains() through emaildomain.IsAlias(), so only the canonical form can create.

A new @hoganlovells.com signup is refused with a message that names what to do instead: "Neue Zugänge nur mit @hlc.com-Adresse. Wenn Sie bereits ein Konto haben, melden Sie sich mit Ihrer bisherigen Adresse an — die funktioniert unverändert weiter."

That is the "accept both at the gate, normalise at creation" shape this issue suggested, implemented.

4. Who owns the decision across the three products — STILL OPEN, and I cannot answer it here

This is the part the issue itself says "makes it an issue rather than a paliad ticket". paliad is settled; m/hihlc and youpc are not something I can measure from this repo, and guessing at their state is exactly what would make this comment worse than silence. Someone with those two repos has to say whether they canonicalised the same way, and whether anyone owns the pair going forward.

One side effect worth naming

Dropping hlc.de bites on sign-IN, not just registration, so its holders are locked out at their next login. There is exactly 1 @hlc.de account on prod — a dormant tester@ global_admin. m's own account is not affected. Noting it so it is a known consequence rather than a surprise.

Verdict: partially resolved. Items 1-3 done and measured; item 4 open and cross-product. Not closing — that is m's.

## Three of the four items are done. The fourth is the cross-product one and I cannot answer it from paliad. **What I ran** — read-only queries against prod, plus the auth and `internal/emaildomain` code paths. Going through the issue's own list rather than assuming m's ruling settled all of it. ### 1. Which form is canonical — **DONE** m ruled 2026-07-27: `hlc.com` canonical, `hoganlovells.com` alias, `hlc.de` dropped. `internal/emaildomain` carries the split. ### 2. What happens to accounts on the non-canonical form — **DONE, and the migration has already run** The issue records *"51 users today, all on `hoganlovells.com`"*. That is no longer the state. On prod now: | domain | auth.users | |---|---| | `hlc.com` | **60** | | `hoganlovells.com` | **0** | And the reconciliation is clean: - `paliad.users` on `hoganlovells.com`: **0**; on `hlc.com`: **47** - `paliad.users` ↔ `auth.users` email mirror drift: **0** - humans holding *both* forms: **0** The accounts were renamed rather than duplicated, and `cmd/canonicalize-emails` is the machinery that did it. The concrete risk the issue was filed about — *"a second, empty account… same human, no projects"* — has zero instances. Sign-in still accepts the alias and says so rather than failing: `handleAPILogin` returns a `notice` telling the user their address moved to `@hlc.com` and that **the old one keeps working**. ### 3. Whether signup should refuse the non-canonical form — **DONE** This is the item that would have let the problem regrow, so it is worth spelling out. There are two gates, deliberately different: - `isAllowedEmailDomain` — **sign-IN**, still accepts `hoganlovells.com`, so no existing holder is locked out. - `isCreatableEmailDomain` — every path that **mints a new identity** (register, both admin-create paths, invitation recipients). It filters `AllowedEmailDomains()` through `emaildomain.IsAlias()`, so only the canonical form can create. A new `@hoganlovells.com` signup is refused with a message that names what to do instead: *"Neue Zugänge nur mit @hlc.com-Adresse. Wenn Sie bereits ein Konto haben, melden Sie sich mit Ihrer bisherigen Adresse an — die funktioniert unverändert weiter."* That is the "accept both at the gate, normalise at creation" shape this issue suggested, implemented. ### 4. Who owns the decision across the three products — **STILL OPEN, and I cannot answer it here** This is the part the issue itself says *"makes it an issue rather than a paliad ticket"*. paliad is settled; **m/hihlc and youpc are not something I can measure from this repo**, and guessing at their state is exactly what would make this comment worse than silence. Someone with those two repos has to say whether they canonicalised the same way, and whether anyone owns the pair going forward. ### One side effect worth naming Dropping `hlc.de` bites on **sign-IN**, not just registration, so its holders are locked out at their next login. There is exactly **1** `@hlc.de` account on prod — a dormant `tester@` `global_admin`. m's own account is not affected. Noting it so it is a known consequence rather than a surprise. --- **Verdict: partially resolved.** Items 1-3 done and measured; item 4 open and cross-product. Not closing — that is m's.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#159
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?