Compare commits
2 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| ecfdfa939b | |||
| 47dae603ac |
@@ -1,11 +0,0 @@
|
||||
{
|
||||
"mcpServers": {
|
||||
"gitea": {
|
||||
"type": "http",
|
||||
"url": "https://git-mcp.farh.net/mcp",
|
||||
"headers": {
|
||||
"Authorization": "Bearer ${GITEA_TOKEN}"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -165,8 +165,6 @@ Geocoding turns a client's street address into `latitude`/`longitude` + `geocode
|
||||
| TC-API-3.19b | Get pet profile summary — customer cross-tenant blocked (GRO-2013) | Sign in as `uat-customer@groombook.dev`; reuse the customer's sessionId from TC-API-3.19a; `GET /api/pets/{otherClientPetId}/profile-summary` for a pet owned by a different client (`c0000002-...` or any non-customer pet) | 403 Forbidden (owner-bypass requires session.clientId === pet.clientId) |
|
||||
| TC-API-3.19c | Get pet profile summary — customer without portal session header | Same as TC-API-3.19a but omit the `X-Impersonation-Session-Id` header | 403 Forbidden (no owner-bypass without valid portal session) |
|
||||
| TC-API-3.19d | Get pet profile summary — owner-bypass writes audit row (GRO-2063) | Same setup as TC-API-3.19a (sign in as `uat-customer@groombook.dev`, establish a portal session for the customer's own clientId, call `GET /api/pets/{ownPetId}/profile-summary` with `X-Impersonation-Session-Id: {sessionId}` and a 200 OK response). Then call `GET /api/impersonation/sessions/{sessionId}/audit-log` and confirm there is exactly one entry with `action === "read_profile_summary"`, `pageVisited` matching the profile-summary path, and `metadata` containing `petId` and `actorStaffId` for the customer. Repeat TC-API-3.19b (cross-tenant attempt) and confirm NO new `read_profile_summary` row was written for the cross-tenant attempt. | 200 OK on the profile-summary call AND an audit log entry is present with the correct shape (defense-in-depth audit row; bypass attempts against other clients must NOT log) |
|
||||
| TC-UAT-2 | Groomer accesses linked pet profile summary (GRO-2100) | Sign in as `uat-groomer@groombook.dev`; `GET /api/pets/c0000001-0000-0000-0000-000000000002/profile-summary` (UAT Pup Alpha — linked via deterministic completed appointment `a0000001-0000-0000-0000-000000000001`, service `b0000001-…-0001` "Bath & Brush", `startTime` ~7 days ago) | 200 OK, `recentGroomingHistory[]` non-empty (>=1 entry), `visitCount >= 1`, `upcomingAppointment` null (the seeded appointment is in the past) |
|
||||
| TC-UAT-3 | Groomer blocked from unlinked pet profile summary (GRO-2100) | Sign in as `uat-groomer@groombook.dev`; `GET /api/pets/c0000001-0000-0000-0000-000000000003/profile-summary` (UAT Pup Beta — intentionally UNLINKED; no appointment row references this pet's clientId+groomerId combo) | 403 Forbidden (RBAC `groomer` role lacks the appointment-linkage grant for this pet). NOTE: if 404 is returned instead of 403, file a separate RBAC defect (not against the seed) — see GRO-2100 verification note |
|
||||
| TC-API-3.29 | Get pet profile summary — unknown UUID returns 404 (GRO-2014) | GET /api/pets/00000000-0000-0000-0000-000000000001/profile-summary while authenticated (any role) | 404 Not Found with body `{"error":"Not found"}` (was empty-body 500 in GRO-2014) |
|
||||
| TC-API-3.30 | Get pet profile summary — malformed UUID returns 404 (GRO-2014) | GET /api/pets/not-a-uuid/profile-summary while authenticated | 404 Not Found with body `{"error":"Not found"}` (was empty-body 500 in GRO-2014 — Postgres uuid cast failure) |
|
||||
| TC-API-3.31 | Get pet profile summary — never empty-body 500 (GRO-2014) | GET /api/pets/{anyId}/profile-summary across the test sweep | No response has status 500 with an empty body. Any 500 must include a JSON body `{"error":"Internal Server Error"}` |
|
||||
|
||||
@@ -177,10 +177,7 @@ describe("PATCH /portal/pets/:petId", () => {
|
||||
expect(persisted.weightKg).toBe("18.25");
|
||||
expect(persisted.groomingNotes).toBe("old grooming notes");
|
||||
expect(persisted.healthAlerts).toBe("Allergic to oatmeal shampoo");
|
||||
// photoKey is NOT writable via portal PATCH (GRO-2187 S3 key-hijack fix):
|
||||
// the web form round-trips the GET-shaped photoUrl, but the server must not
|
||||
// persist it. Photo changes go through the key-validated upload flow.
|
||||
expect(persisted.photoKey).toBeUndefined();
|
||||
expect(persisted.photoKey).toBe("pets/rex.jpg");
|
||||
expect(persisted.coatType).toBe("double");
|
||||
expect(persisted.petSizeCategory).toBe("extra_large");
|
||||
expect(persisted.preferredCuts).toEqual(["teddy bear", "puppy cut"]);
|
||||
@@ -190,55 +187,6 @@ describe("PATCH /portal/pets/:petId", () => {
|
||||
expect(persisted.updatedAt).toBeInstanceOf(Date);
|
||||
});
|
||||
|
||||
// GRO-2187 security regression: a portal customer must not be able to set the
|
||||
// S3 object key. photoKey is consumed server-side by getPresignedGetUrl /
|
||||
// deleteObject; the upload path guards keys with a pets/{petId}/ prefix, and the
|
||||
// portal PATCH must not offer a bypass. A foreign/arbitrary photoUrl is accepted
|
||||
// (Zod strips the unknown key) but must leave photoKey untouched.
|
||||
it("does not mutate photoKey when a foreign photoUrl is supplied (200)", async () => {
|
||||
selectSessionRow = ACTIVE_SESSION;
|
||||
const ownKey = `pets/${PET_ID}/original.jpg`;
|
||||
selectPetRow = { ...PET, photoKey: ownKey };
|
||||
|
||||
const res = await jsonPatch(
|
||||
`/portal/pets/${PET_ID}`,
|
||||
{
|
||||
name: "Rex",
|
||||
// attacker-chosen key pointing at another tenant's object
|
||||
photoUrl: "pets/00000000-0000-0000-0000-0000000000ff/victim-secret.jpg",
|
||||
},
|
||||
{ "X-Impersonation-Session-Id": SESSION_ID }
|
||||
);
|
||||
|
||||
expect(res.status).toBe(200);
|
||||
const persisted = updatedValues[0]!;
|
||||
// The attacker-supplied key never reaches the update payload.
|
||||
expect(persisted.photoKey).toBeUndefined();
|
||||
// And the stored key is unchanged from the pet's own value.
|
||||
const body = await res.json();
|
||||
expect(body.photoUrl).toBe(ownKey);
|
||||
});
|
||||
|
||||
// The length/array caps live in the Zod schema, so violations are rejected by
|
||||
// zValidator with 400 (in-handler enum checks are what return 422).
|
||||
it("returns 400 when a medicalAlert description exceeds the length cap", async () => {
|
||||
selectSessionRow = ACTIVE_SESSION;
|
||||
selectPetRow = PET;
|
||||
|
||||
const res = await jsonPatch(
|
||||
`/portal/pets/${PET_ID}`,
|
||||
{
|
||||
medicalAlerts: [
|
||||
{ type: "allergy", description: "x".repeat(2001), severity: "low" },
|
||||
],
|
||||
},
|
||||
{ "X-Impersonation-Session-Id": SESSION_ID }
|
||||
);
|
||||
|
||||
expect(res.status).toBe(400);
|
||||
expect(updatedValues).toHaveLength(0);
|
||||
});
|
||||
|
||||
it("falls back to the weight key when weightKg is absent", async () => {
|
||||
selectSessionRow = ACTIVE_SESSION;
|
||||
selectPetRow = PET;
|
||||
|
||||
+6
-11
@@ -261,8 +261,8 @@ const PORTAL_PET_SIZE_ALIASES: Record<string, string> = { xlarge: "extra_large"
|
||||
|
||||
const portalMedicalAlertSchema = z.object({
|
||||
id: z.string().optional(),
|
||||
type: z.string().max(2000),
|
||||
description: z.string().max(2000),
|
||||
type: z.string(),
|
||||
description: z.string(),
|
||||
severity: z.enum(["low", "medium", "high"]),
|
||||
});
|
||||
|
||||
@@ -275,16 +275,12 @@ const portalPetUpdateSchema = z.object({
|
||||
birthDate: z.string().nullable().optional(),
|
||||
notes: z.string().max(2000).nullable().optional(),
|
||||
healthAlerts: z.string().max(2000).nullable().optional(),
|
||||
// photoUrl/photoKey are intentionally NOT writable here: photoKey is a trusted
|
||||
// S3 object key consumed server-side (getPresignedGetUrl / deleteObject), and the
|
||||
// upload path (pets.ts) already enforces a pets/{petId}/ prefix guard against key
|
||||
// hijacking. Photo changes go through the dedicated upload + /photo/confirm flow.
|
||||
// The web form round-trips the GET-shaped photoUrl; Zod strips it as an unknown key.
|
||||
photoUrl: z.string().nullable().optional(),
|
||||
// coatType / petSizeCategory validated in-handler so bad values return 422.
|
||||
coatType: z.string().nullable().optional(),
|
||||
petSizeCategory: z.string().nullable().optional(),
|
||||
preferredCuts: z.array(z.string().max(2000)).max(50).nullable().optional(),
|
||||
medicalAlerts: z.array(portalMedicalAlertSchema).max(50).nullable().optional(),
|
||||
preferredCuts: z.array(z.string()).nullable().optional(),
|
||||
medicalAlerts: z.array(portalMedicalAlertSchema).nullable().optional(),
|
||||
});
|
||||
|
||||
portalRouter.patch(
|
||||
@@ -326,8 +322,7 @@ portalRouter.patch(
|
||||
|
||||
if (body.notes !== undefined) updateData.groomingNotes = body.notes;
|
||||
if (body.healthAlerts !== undefined) updateData.healthAlerts = body.healthAlerts;
|
||||
// photoKey is intentionally not writable here — see portalPetUpdateSchema note.
|
||||
// Photo changes go through the key-validated upload + /photo/confirm flow.
|
||||
if (body.photoUrl !== undefined) updateData.photoKey = body.photoUrl;
|
||||
|
||||
if (body.coatType !== undefined) {
|
||||
if (body.coatType !== null && !PORTAL_COAT_TYPES.includes(body.coatType)) {
|
||||
|
||||
Reference in New Issue
Block a user