devsyncwrld/backspace
1
0
Fork 0
Code Issues Pull Requests Actions 26 Packages Projects Releases Wiki Activity

fix(dm): owner-only group DM ops accept federated target identification

Browse Source 
Transferring ownership or kicking a member surfaced "Target user is not a
member of this DM channel" whenever the target was a federated user.

Root cause: the client passed `canonical.id` from `useCanonicalUserView`,
which returns the user's HOME id when the home view is in the userViews
cache. After owner-routing the request to the owner instance, that
instance's `dm_members.userId` (its own local replicated id) never
matched the home id, so `isDmMember` returned false. The same failure
mode applied across any cross-instance scenario where the
channel-serving instance and the owner-serving instance disagree on the
local replicated user id for the same federated user.

Fix: both endpoints now accept federated identification, mirroring the
existing pattern on `POST /api/dm/:id/members`:

- `POST /api/dm/:id/transfer` body: `{ newOwnerId? } | { homeUserId, homeInstance }`.
  Federated args win when both are supplied (strictly more specific).
- `DELETE /api/dm/:id/members/:targetUserId` reads optional
  `?homeInstance=<origin>` query; when present, the URL segment is
  treated as a homeUserId and resolved via `resolveOrCreateReplicatedUser`.

Client `api.dm.kickMember` and `api.dm.transferOwnership` gain an
optional `federated` argument; `DmRosterPanel` and `MobileGroupDmInfo`
pass it whenever the target has `homeUserId` + `homeInstance` populated.

Adds 5 server tests (3 transfer + 2 kick) covering federated targets,
the federated-wins-over-local precedence rule, and federated-non-member
rejection. Updates 2 client routing tests and 2 DmRosterPanel test
assertions for the new signature. Updates `docs/systems/dm-system.md`
and `docs/systems/api.md`.

Server: 965 tests pass (was 960). Web: 362 tests pass (was 360).
This commit is contained in:
Jannis Braun
2026-05-10 22:09:14 +02:00
parent 9279ac78e5
commit b6842c5590
11 changed files with 442 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
packages/server/src/routes/dm.ts
+95 -8
View File
@@ -1976,11 +1976,43 @@ export async function dmRoutes(app: FastifyInstance): Promise<void> {
return reply.code(200).send({ success: true });
});
// DELETE /api/dm/:id/members/:targetUserId - Owner kicks a member from a group DM
app.delete<{ Params: { id: string; targetUserId: string } }>('/api/dm/:id/members/:targetUserId', async (request, reply) => {
const { id, targetUserId } = request.params;
// DELETE /api/dm/:id/members/:targetUserId - Owner kicks a member from a group DM.
//
// The `:targetUserId` URL segment carries either a local user id OR a
// federated home user id. When the optional `homeInstance` query string is
// present, the segment is interpreted as a home id and resolved via
// `resolveOrCreateReplicatedUser(targetUserId, homeInstance)` — same pattern
// as POST /api/dm/:id/transfer and POST /api/dm/:id/members. This is
// necessary when the client only knows the target's home identity (the
// common case for federated members rendered through `useCanonicalUserView`,
// whose `id` is the home id, not this instance's local replicated id).
// Without this path, the membership check `isDmMember(id, targetUserId)`
// fails because `dm_members.userId` on the owner instance is its local
// replicated id, not the federated home id.
app.delete<{
Params: { id: string; targetUserId: string };
Querystring: { homeInstance?: string };
}>('/api/dm/:id/members/:targetUserId', async (request, reply) => {
const { id, targetUserId: rawTargetSegment } = request.params;
const homeInstanceQuery = request.query?.homeInstance;
const db = getDb();
// Resolve the target to a local user row. When `homeInstance` is supplied,
// treat the URL segment as a homeUserId. Otherwise, treat it as a local
// user id and look it up directly.
let targetUserRow: typeof schema.users.$inferSelect | undefined;
if (typeof homeInstanceQuery === 'string' && homeInstanceQuery.length > 0) {
targetUserRow = resolveOrCreateReplicatedUser(rawTargetSegment, homeInstanceQuery, db) ?? undefined;
} else {
targetUserRow = db.select().from(schema.users).where(eq(schema.users.id, rawTargetSegment)).get();
}
if (!targetUserRow) {
return reply.code(404).send({ error: 'User not found', statusCode: 404 });
}
const targetUserId = targetUserRow.id;
// Channel must exist (and not be soft-deleted)
const dmChannel = db.select().from(schema.dmChannels).where(and(eq(schema.dmChannels.id, id), isNull(schema.dmChannels.deletedAt))).get();
if (!dmChannel) {
@@ -2021,17 +2053,72 @@ export async function dmRoutes(app: FastifyInstance): Promise<void> {
return reply.code(200).send({ success: true });
});
// POST /api/dm/:id/transfer - Owner transfers ownership to another group member without leaving
app.post<{ Params: { id: string }; Body: { newOwnerId?: unknown } }>('/api/dm/:id/transfer', async (request, reply) => {
// POST /api/dm/:id/transfer - Owner transfers ownership to another group member without leaving.
//
// Body accepts either a local id (`newOwnerId`) or a federated identity
// (`homeUserId` + `homeInstance`). Federated identification mirrors the
// `addDmMember` pattern (see `POST /api/dm/:id/members` above) and is
// required when the client only knows the target's home identity — for
// example when the channel-serving instance and the owner-serving instance
// disagree on the local replicated user id, or when `useCanonicalUserView`
// surfaces the user's home view (whose `id` is the home id, NOT this
// instance's local replicated id). Without this path, transferring ownership
// to a federated member always failed with "user is not part of the DM"
// because the owner instance's `dm_members.userId` is its OWN local id, not
// the federated home id.
app.post<{
Params: { id: string };
Body: {
newOwnerId?: unknown;
homeUserId?: unknown;
homeInstance?: unknown;
};
}>('/api/dm/:id/transfer', async (request, reply) => {
const { id } = request.params;
const newOwnerId = (request.body as { newOwnerId?: unknown } | null)?.newOwnerId;
const body = (request.body ?? {}) as {
newOwnerId?: unknown;
homeUserId?: unknown;
homeInstance?: unknown;
};
const rawNewOwnerId = body.newOwnerId;
const rawHomeUserId = body.homeUserId;
const rawHomeInstance = body.homeInstance;
if (typeof newOwnerId !== 'string' || newOwnerId.length === 0) {
return reply.code(400).send({ error: 'newOwnerId is required', statusCode: 400 });
const hasFederatedArgs =
typeof rawHomeUserId === 'string' && rawHomeUserId.length > 0 &&
typeof rawHomeInstance === 'string' && rawHomeInstance.length > 0;
const hasLocalArg = typeof rawNewOwnerId === 'string' && rawNewOwnerId.length > 0;
if (!hasFederatedArgs && !hasLocalArg) {
return reply.code(400).send({
error: 'newOwnerId or (homeUserId + homeInstance) is required',
statusCode: 400,
});
}
const db = getDb();
// Resolve the new owner to a local user row. Federated identification
// takes precedence when both forms are supplied — it's strictly more
// specific (homeUserId + homeInstance disambiguates across instances),
// so the explicit federated args wins over a possibly-stale local id.
let newOwnerRow: typeof schema.users.$inferSelect | undefined;
if (hasFederatedArgs) {
newOwnerRow = resolveOrCreateReplicatedUser(
rawHomeUserId as string,
rawHomeInstance as string,
db,
) ?? undefined;
} else {
newOwnerRow = db.select().from(schema.users).where(eq(schema.users.id, rawNewOwnerId as string)).get();
}
if (!newOwnerRow) {
return reply.code(404).send({ error: 'User not found', statusCode: 404 });
}
const newOwnerId = newOwnerRow.id;
// Channel must exist (and not be soft-deleted)
const dmChannel = db.select().from(schema.dmChannels).where(and(eq(schema.dmChannels.id, id), isNull(schema.dmChannels.deletedAt))).get();
if (!dmChannel) {