syncode/identity

feat: Promote Identity 0.4 #22

Merged

day01 merged %!d() commits from %!s() into %!s()

2026-08-25 11:38:47 +00:00

day01 commented

2026-08-25 11:38:23 +00:00

Owner

Promote the verified 0.4 implementation from develop to main after successful dev cutover, E2E, resilience tests and architecture audit.

day01 added 63 commits 2026-08-25 11:38:25 +00:00

feat: OAuth2/PKCE login backend (stage 3), starting with GitHub

		api-oauth crate handles start/callback for the authorization code flow
with PKCE, CSRF state carried in a short-lived signed cookie instead of
server-side storage. storage gains auth_provider/linked_identity
lookups against stage 1's existing schema. main.rs merges the oauth
router into the HTTP listener alongside GraphQL, since both are
reached by the browser now.

feat: GraphQL account API — me, unlinkIdentity, logout endpoint

		me resolves the current user from the session cookie (no separate
auth mutation needed, same cookie the OAuth callback already sets).
unlinkIdentity refuses to drop a user to zero identities, since
nothing else can start them a session. CORS is scoped to the same
allowed_redirect_origins stage 3 already validates redirect_to
against, since the front calling GraphQL cross-subdomain is the same
trust boundary.

feat: pull the primary email from GitHub on login

		GET /user/emails needs the App's Email addresses permission — until
that's granted on GitHub's side this just silently finds nothing,
same as any other best-effort profile fetch failing. Also fixes two
account.rs integration tests colliding on fixed usernames across
repeated runs against the same test database.

feat: sync every provider email, not just the primary

		GitHub's /user/emails returns the full list; upsert_email now takes
verified/primary per row instead of assuming exactly one email, so a
secondary address survives alongside the primary instead of only ever
tracking one.

feat: manual email addition with mailed verification

		addEmail sends a link instead of adding the address outright, since
an unverified address is worse than none once anything trusts
verified. GET /email/verify needs no session — the token is the proof,
because the browser opening the link may not be the one that asked
for it. New mailer crate wraps lettre/SMTP behind the same interface
shape as the rest of the app's external-service calls.

feat: link a second account, and put email ownership in the user's hands

		Linking: /auth/{provider}/start?mode=link attaches a provider to the
already-signed-in user instead of logging in — the callback branches
on link_user_id carried through the pending cookie, and reuses the
existing session rather than issuing a new one.

Emails: is_primary is no longer whatever a provider called primary —
that was never something the user chose. sync_provider_email leaves
it alone except to bootstrap the very first email; setPrimaryEmail is
the only way it changes after that. source (github/manual) lets
removeEmail refuse provider-sourced rows a login would just recreate.

feat: pending email verifications, resend, and a cooldown

		addEmail already worked as a de-facto resend when called again with
the same address; the gap was visibility — nothing showed a request
was in flight. me.pendingEmailVerifications surfaces it (one row per
address, newest token), and a 60s cooldown keeps repeat clicks from
queuing a mail each time.

Split api-graphql into query/mutation modules — lib.rs was closing in
on the 250-line limit before this addition.

feat: wire GitLab, Codeberg, and Google alongside GitHub

		The callback handler was hardcoded to GitHub's two-call fetch — a
single fetch_profile(provider_kind, token) dispatch replaces it, with
each provider module owning its own API shape (GitLab and Google
return one call's worth of user+email, GitHub and Codeberg two).
Nothing changes about auth_provider or the OAuth flow itself; every
provider still just needs a row with its client id/secret and OAuth
endpoints to go live.

feat: track every provider that vouches for an email, and fetch avatars

		An address confirmed by two linked providers used to silently lose
one source on every sync — user_email_source normalizes that into a
proper set instead of a single overwritten column. removeEmail now
checks 'does any provider still claim this' instead of a literal
'manual' string.

Also pulls avatar_url from each provider's profile response and
refreshes it (and the username) on every login, not just the first —
linked accounts were showing neither before.

feat: own the account-deletion decision (confirm/restore/sweep)

		Mirrors the email_verification pattern: a mailed confirm link starts
the flow, a hashed token proves it, and a second mailed restore link
undoes it within 30 days. The account lock/unlock/hard-delete itself
still happens in Gitea (repo/org/package ownership lives there), so
the confirm handler calls into Gitea's new private API before
committing confirmed_at — a still-owned account gets a specific
reason back instead of a silent lock.

New crate gitea-client wraps that internal API (same shared secret
syncode-control already uses). An hourly sweep in main.rs hard-deletes
accounts whose restore window has closed.

feat: Faza 1 data-migration seeding + claim-account by verified email

		Adds the storage/binary side of the one-time ETL that backfills
syncode-identity from Gitea's existing users/orgs/teams/repos/grants
(0.4 stage 4, Faza 1): idempotent seed_* functions (upsert by natural
key — username, slug, org+name, owner+name — so the import tool is
safe to re-run) plus a new insert_repository, and a bin/import_seed
that reads the Go side's export-seed JSON and writes back a
{gitea_id: uuid} mapping for Go's identity_link backfill. Grant rows
aren't deduplicated on re-run — harmless since capabilities are
unioned, not counted, but means this only runs once per environment
against a reviewed file.

Also changes find_or_create_user_by_link to check verified_emails
against user_email before creating a new user — a match on both this
forge's and the login's independently-verified claim is what makes
Faza 1's pre-seeded accounts (verified email, no linked_identity yet)
claimable on first login instead of ending up duplicated, and covers
the same case organically for anyone linking a second provider that
shares a verified address with their first.

Merge pull request 'feat: 0.4 stage 4 — account deletion owned by identity + Faza 1 data migration' (#5) from etap4/faza1-data-migration into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/5⁩

build: ship import_seed alongside the service image

		Faza 1's migration needs to run against dev/prod's real Postgres, which
isn't reachable from outside the compose network — shipping the binary
in the image lets it run as a one-off via
\`docker compose run --entrypoint import_seed identity ...\` instead of
requiring a separate build/deploy path just for this tool.

Merge pull request 'build: ship import_seed alongside the service image' (#6) from etap4/ship-import-seed-binary into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/6⁩

feat: org/team/grant management backend (Etap 5, część 1)

		Bootstraps organization-admin grants for each org's Owners team (Faza 1
only ever seeded repo-level grants), and adds storage + GraphQL
plumbing for teams and grants: list/create/delete teams, add/remove
members, grant and revoke repository access, all authorized via a new
require_capability GraphQL guard mirroring the gRPC bridge's existing
check_capability.

feat: expose a team's active grants through GraphQL

		Team.grants (id, resource, capabilities) lists what the frontend needs
to render and revoke existing grants — without it, revokeGrant had no
way to discover a grant id to act on.

test: GraphQL-level coverage for org/team/grant mutations

		Exercises the actual HTTP GraphQL endpoint (cookie session, real
resolvers) rather than just storage — covers the FORBIDDEN path for a
non-admin, a full team/member/grant round trip, and the cross-org
security check on revokeGrant (an org-B admin can't revoke an org-A
grant by guessing its id).

Merge pull request 'feat: org/team/grant management backend (Etap 5, część 1)' (#7) from etap5/org-team-permissions into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/7⁩

feat: encrypt and persist linked identities' OAuth tokens

		The GitHub/GitLab access (and refresh, when given) tokens from an OAuth
exchange were fetched once for the profile call and then dropped —
nothing persisted them. The new heatmap sync jobs (0.4 stage 5, część
2) need to call these providers' APIs later in the background, so the
callback now encrypts and stores them via a new syncode-identity-token-
crypto crate (ChaCha20-Poly1305, key from
SYNCODE_IDENTITY_TOKEN_ENCRYPTION_KEY). Drops the long-dead, never-
written linked_identity.token_ref column in favor of proper
access/refresh/expiry columns.

feat: cyclic background sync of native/GitHub/GitLab contributions

		Three 24h tokio::spawn loops (mirroring the existing deletion sweep):
native pulls per-repo, per-day counts from Gitea's new internal
heatmap endpoint and resolves them into identity's own repository ids;
GitHub/GitLab pull from each provider's contribution API using the
tokens saved by the previous commit, splitting public/private per
provider's own shape (GitHub: diff against its unauthenticated public
events; GitLab: each event's project visibility directly). All three
upsert into contribution_day.

Also fixes a real pre-existing gap in that table's unique constraint:
Postgres never treats NULL as equal to NULL for uniqueness, and every
row here has source_provider_id or source_resource_id NULL by design,
so the original UNIQUE(...) silently allowed duplicates. A
COALESCE-to-sentinel index closes it.

feat: expose the heatmap over GraphQL — userHeatmap, setHeatmapPrivacy

		userHeatmap(username) returns three layers: native (each day filtered
by whether the viewer can read that repository — public repos always,
private ones only with an active read grant, reusing the same
resolve_effective_capabilities machinery Etap 5 część 1 built), linked
public (always shown), and linked private (gated by
heatmap_privacy_setting's opt-in and audience). Works for an anonymous
caller too, since public data shouldn't require signing in to see.

setHeatmapPrivacy is a personal-setting mutation, checked by identity
rather than require_capability — nobody else's grant should be able to
flip someone's own privacy preference.

GraphQL-level tests cover the security-relevant paths: a private
repo's contributions are invisible without a grant and appear once one
exists, and linked-private honors both the opt-in and the audience.

feat: add myHeatmapPrivacy query for reading the caller's own setting

		The front's privacy toggle needs to show the currently saved
show_private_external/audience, not just write a new one blind.

Merge pull request 'feat: OAuth token encryption, background contribution sync, heatmap GraphQL (Etap 5, część 2)' (#8) from etap5/heatmap into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/8⁩

feat: add the missing Codeberg contribution sync job

		Codeberg was one of the three linkable providers but had no sync job
at all — a real gap, not the "needs a relink" situation GitHub/GitLab
are in. Codeberg (a Forgejo instance) still exposes the same
unauthenticated /users/{u}/heatmap endpoint this fork just removed
from its own public surface, so no token is needed — always
linked_public, since that endpoint never returns anything a private
caller couldn't already see.

Merge pull request 'feat: add the missing Codeberg contribution sync job' (#9) from etap5/heatmap-codeberg into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/9⁩

feat: per-provider heatmap breakdown, much deeper linked-account history

		userHeatmap's linkedPublic/linkedPrivate now return one entry per
provider (GitHub/GitLab/Codeberg) instead of a single merged sum, so
the front can offer per-provider filtering instead of only a combined
view.

Also reaches much further back: GitHub's contributionsCollection loops
across up to 10 one-year windows (its API rejects a wider single span),
GitLab's /events is now paginated up to 20 pages instead of one. Both
were previously capped at ~365 days for no real reason beyond "that's
what fit in one call."

Merge pull request 'feat: per-provider heatmap breakdown, much deeper linked-account history' (#10) from etap5/heatmap-per-provider into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/10⁩

build: add .dockerignore to exclude target/ from the build context

		A local target/ directory (release + debug artifacts, easily 10+ GB
after a normal working session) was getting uploaded as Docker build
context on every manual `docker buildx build` — CI never hits this
since it always starts from a clean checkout, but it made a local
rebuild (needed today when the amd64 CI runner sat queued indefinitely)
take much longer than it should have.

Merge pull request 'build: add .dockerignore to exclude target/ from the build context' (#11) from etap5/heatmap-dockerignore into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/11⁩

fix: validate OAuth redirect origins

Merge remote-tracking branch 'origin/develop' into feat/identity-stage4-hardening

Merge pull request 'fix: validate OAuth redirect origins' (#12) from feat/identity-stage4-hardening into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/12⁩

feat: add LocalAgent sessions and credentials

Merge pull request 'feat: add LocalAgent sessions and credentials' (#13) from feat/local-agent-stage6 into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/13⁩

fix: enforce LocalAgent capability boundaries

fix: validate Git token audience scope

Merge pull request 'fix: enforce LocalAgent capability boundaries' (#14) from feat/local-agent-stage6-hardening into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/14⁩

feat: add PlatformAgent identity

Merge pull request 'feat: add PlatformAgent identity' (#15) from feat/platform-agent-stage7 into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/15⁩

feat: issue scoped repository tokens

Merge pull request 'feat: issue scoped repository tokens' (#16) from feat/syn-cli-stage8 into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/16⁩

feat: add access tokens and branch protection

Merge pull request 'feat: add access tokens and branch protection' (#17) from feat/identity-stage9 into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/17⁩

fix: Make identity grant import idempotent

Merge pull request 'fix: Make identity grant import idempotent' (#18) from feat/identity-stage9-etl into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/18⁩

feat: add identity settings lifecycle

refactor: compile identity queries

feat: complete identity settings transports

refactor: enforce identity application boundaries

refactor: isolate identity OAuth workflows

refactor: strengthen identity domain workflows

feat: complete identity authority cutover

fix: harden identity dependencies

fix: validate identity migrations in CI

fix: prepare SQLx metadata from fresh schema

Merge pull request 'Complete 0.4 dev cutover' (#19) from feat/complete-0.4-dev into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/19⁩

refactor: use semantic identity types

fix: enforce semantic identity types

Merge pull request 'refactor: use semantic identity types' (#20) from feat/strong-identity-ids into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/20⁩

fix: require Forge user projection on login

fix: keep SQLx metadata from fresh schema

refactor: split OAuth projection modules

Merge pull request 'fix: require Forge user projection on login' (#21) from feat/user-projection-cutover into develop

		Reviewed-on: ⁨https://syncode.sh/syncode/identity/pulls/21⁩

day01 merged commit 8e35765ee2 into %!s()

2026-08-25 11:38:47 +00:00

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: syncode/identity#22