* fix(assistant): stop cross-user conversation access, bricked threads and lost sessions Hotfix batch (PR1 of the assistant UI makeover, dev_docs/assistant_redesign_plan.md section 7). No visual change; each of these is wrong today regardless of which design lands, and three are unrecoverable per incident. /api/agent/invoke never checked who owns a resumed conversation_id. RLS on agent_conversations/agent_messages is company-scoped, not user-scoped (20260517204000), so a member could post a colleague's conversation id, have their history loaded into the prompt and read it back, while their own turns were appended to that thread. The conversations list route filters on user_id for exactly this reason. Also pins company and intent: resuming a thread from another company would mix ledgers, and resuming under a different intent would swap the tool whitelist under history the model has already seen. A turn persists the assistant message carrying tool_use blocks before the tools run, and their results only after the batch finishes. Dying in between (client disconnect terminating the function, a deploy, a slow tool) left history ending on an unanswered tool_use, which the Messages API rejects on replay: every later turn 400s, and agent_messages is append-only for the BFL trail, so nothing could repair it. History is now patched on read by synthesizing is_error tool_results, leaving the stored trail untouched. check_and_increment_agent_quota is SECURITY DEFINER in public with a caller-chosen p_user_id, so any authenticated user could drain a colleague's minute/day budget and lock them out of every agent endpoint. A plain REVOKE would break the limiter (all three callers use the user's RLS client) and, as it fails open, silently remove the spend cap: the function now refuses to act for anyone but the caller, while service-role connections keep passing an explicit id. The single reject route re-read status and then wrote unguarded, so losing the race with commit's atomic pending -> committing claim stamped `rejected` over an operation that had already posted a verifikat, invisible to the committing-state recovery sweep. Guarded on status like bulk-reject already is; a lost race is now a 409. The sheet's Escape handler listened on window with no defaultPrevented or target check while the sheet is deliberately non-modal, so pressing Esc to dismiss the reject-reason Select inside an approval card, the command palette or any dialog unmounted the sheet and discarded the conversation, the streaming turn and the un-actioned proposal. It now yields to open overlays and to focus outside the sheet. Verified: 9526 unit tests pass, lint clean on touched files, guards pass, and the new pg-real test proves the quota guard against real Postgres (attacker raises 42501, victim counters stay at 0). The four unrelated pg-real failures on this machine reproduce identically with these changes stashed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(assistant): close anon path on the quota RPC, order the ownership check ahead of writes Review follow-ups on the hotfix batch. The caller guard used auth.uid() alone, which is NULL for the `anon` role just as it is for backend roles, so an unauthenticated caller holding the public anon key (it ships in the browser bundle) could still pick any p_user_id and drain that user's quota. The guard now keys on the request role: anon and authenticated may only ever spend their own quota, backend roles keep passing an explicit id. The default PUBLIC execute grant is revoked as a second layer, with execute granted only to authenticated and service_role. Covered by a new pg test for the anon path. The ownership check ran after the onboarding.intake stamp, so a request that was about to be rejected could still write intake_completed_at. It now sits directly after the capability gate, ahead of every side effect and ahead of the company and profile reads, which also makes a rejected request cheaper. The tool-result repair matched ids anywhere in the history, but the API needs results in the message IMMEDIATELY after the tool_use. A result persisted after an intervening turn (two turns racing on one conversation) left a shape that still 400s. The repair is now positional, and orphaned or late-duplicate tool_results are dropped, since an unmatched tool_result is rejected just as an unanswered tool_use is. The Escape guard matched the Radix popper wrapper, which stays mounted when a popper is force-mounted; it now requires data-state="open" so a closed popper cannot block Escape for the rest of the session. Both new route errors are Swedish, per the user-facing error rule. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
124 lines
5.1 KiB
TypeScript
124 lines
5.1 KiB
TypeScript
import { NextResponse } from 'next/server'
|
|
import { z } from 'zod'
|
|
import { withRouteContext } from '@/lib/api/with-route-context'
|
|
import { getErrorMessage as getUserErrorMessage } from '@/lib/errors/get-error-message'
|
|
|
|
const RejectBodySchema = z.object({
|
|
rejection_category: z
|
|
.enum(['wrong_category', 'wrong_amount', 'duplicate', 'wrong_period', 'other'])
|
|
.optional(),
|
|
rejection_reason: z.string().max(2000).optional(),
|
|
})
|
|
|
|
/**
|
|
* POST /api/pending-operations/:id/reject
|
|
*
|
|
* Reject a pending operation. Optionally accepts a JSON body with
|
|
* `rejection_category` (fixed enum) and `rejection_reason` (free text). Both
|
|
* are stored on the row so agents can fetch them via gnubok_get_recent_rejections
|
|
* and learn from "no". The body is optional: bodyless POSTs from older
|
|
* clients still mark the op rejected with NULL category/reason.
|
|
*/
|
|
export const POST = withRouteContext<{ params: Promise<{ id: string }> }>(
|
|
'pending_operation.reject',
|
|
async (request, { supabase, companyId }, { params }) => {
|
|
const { id } = await params
|
|
|
|
// Body is optional: accept empty/missing body without rejecting the request.
|
|
// Old clients posted no body; the UI dialog will now post a body, but we
|
|
// keep accepting both shapes to avoid coupling the API to the UI version.
|
|
let rejectionCategory: string | undefined
|
|
let rejectionReason: string | undefined
|
|
const contentLength = request.headers.get('content-length')
|
|
if (contentLength && contentLength !== '0') {
|
|
try {
|
|
const raw = await request.json()
|
|
const parsed = RejectBodySchema.safeParse(raw)
|
|
if (!parsed.success) {
|
|
return NextResponse.json(
|
|
{ error: parsed.error.issues.map((i) => i.message).join('; ') },
|
|
{ status: 400 },
|
|
)
|
|
}
|
|
rejectionCategory = parsed.data.rejection_category
|
|
rejectionReason = parsed.data.rejection_reason?.trim() || undefined
|
|
} catch {
|
|
// Body present but unparseable: fail closed.
|
|
return NextResponse.json({ error: 'Invalid JSON body' }, { status: 400 })
|
|
}
|
|
}
|
|
|
|
const { data: op, error: fetchError } = await supabase
|
|
.from('pending_operations')
|
|
.select('id, status')
|
|
.eq('id', id)
|
|
.eq('company_id', companyId)
|
|
.single()
|
|
|
|
if (fetchError || !op) {
|
|
return NextResponse.json({ error: 'Pending operation not found' }, { status: 404 })
|
|
}
|
|
|
|
if (op.status !== 'pending') {
|
|
// There is no auto-commit path (removed in 20260505190027), so a non-pending
|
|
// status here means the op was resolved explicitly: almost always the user
|
|
// pressed Godkänn in the /pending (Att göra) UI in parallel, or another
|
|
// client already rejected it. Spell that out so an agent doesn't read the
|
|
// generic 409 as "the system committed it behind my back".
|
|
const explained =
|
|
op.status === 'rejected'
|
|
? 'Operation already rejected.'
|
|
: op.status === 'expired'
|
|
? 'Operation already expired and can no longer be rejected.'
|
|
: op.status === 'failed_partial'
|
|
? 'Operation already resolved as failed_partial: it failed after posting an ' +
|
|
'irreversible voucher. It can no longer be rejected; see result_data.posted_ids ' +
|
|
'for what was posted and correct it with a storno if needed.'
|
|
: `Operation already ${op.status}: it was approved explicitly (most likely via the ` +
|
|
'Att göra / pending UI in parallel), not auto-committed. It can no longer be rejected; ' +
|
|
'reverse or correct the resulting verifikat instead.'
|
|
return NextResponse.json(
|
|
{ error: explained, status: op.status },
|
|
{ status: 409 }
|
|
)
|
|
}
|
|
|
|
// The status check above is a read, and commit claims rows atomically
|
|
// (pending -> committing). Without a status guard on the write, a reject
|
|
// that loses that race stamps `rejected` over an operation that has since
|
|
// posted a verifikat: a booked entry whose row says rejected, which the
|
|
// committing-state recovery sweep will never find. Guard the UPDATE the
|
|
// same way bulk-reject does and report a lost race as 409.
|
|
const { data: updated, error: updateError } = await supabase
|
|
.from('pending_operations')
|
|
.update({
|
|
status: 'rejected',
|
|
resolved_at: new Date().toISOString(),
|
|
...(rejectionCategory ? { rejection_category: rejectionCategory } : {}),
|
|
...(rejectionReason ? { rejection_reason: rejectionReason } : {}),
|
|
})
|
|
.eq('id', id)
|
|
.eq('company_id', companyId)
|
|
.eq('status', 'pending')
|
|
.select('id')
|
|
|
|
if (updateError) {
|
|
return NextResponse.json({ error: getUserErrorMessage(updateError) }, { status: 500 })
|
|
}
|
|
|
|
if (!updated || updated.length === 0) {
|
|
return NextResponse.json(
|
|
{
|
|
error:
|
|
'Åtgärden hann behandlas av någon annan och kunde inte avvisas. ' +
|
|
'Ladda om sidan och kontrollera resultatet.',
|
|
},
|
|
{ status: 409 },
|
|
)
|
|
}
|
|
|
|
return NextResponse.json({ data: { id, status: 'rejected' } })
|
|
},
|
|
{ requireWrite: true },
|
|
)
|