Merge pull request #23 from nannany/feat/integration-id-auth

nannany · web-flow · commit 2b0f82430025 · 2025-05-27T13:09:23.000+09:00
feat: Use integration ID and JWT for edge function auth
diff --git a/supabase/functions/task-management/MANUAL_TESTING_GUIDE.md b/supabase/functions/task-management/MANUAL_TESTING_GUIDE.md
@@ -0,0 +1,200 @@
+# Manual Testing Guide for `task-management` Edge Function
+
+This guide provides steps to manually test the `task-management` Supabase edge function after recent modifications.
+
+## 1. Prerequisites
+
+Before testing, ensure the following are set up in your Supabase project:
+
+### 1.1. `integration_keys` Table
+
+- Create a table named `integration_keys` with at least the following columns:
+
+  - `key` (Type: `TEXT` or `VARCHAR`, Unique): Stores the integration key string.
+  - `user_id` (Type: `UUID`, Foreign Key to `auth.users(id)`): The Supabase user ID this key is associated with.
+  - `is_active` (Type: `BOOLEAN`): Whether the key is currently active.
+  - `description` (Type: `TEXT`, Optional): A description for the key.
+
+- **Sample Data**:
+  - **Valid & Active Key**: Insert a row for a user that exists in your `auth.users` table.
+    - `key`: `test-integration-key-active`
+    - `user_id`: (UUID of an existing user, e.g., `12345678-1234-1234-1234-1234567890ab`)
+    - `is_active`: `true`
+    - `description`: "Active key for testing"
+  - **Valid & Inactive Key**: Insert another row.
+    - `key`: `test-integration-key-inactive`
+    - `user_id`: (Same or different UUID of an existing user)
+    - `is_active`: `false`
+    - `description`: "Inactive key for testing"
+
+### 1.2. `tasks` Table
+
+- Ensure you have a `tasks` table. The function attempts to insert into this table.
+- It should have at least these columns:
+  - `title` (Type: `TEXT` or `VARCHAR`)
+  - `description` (Type: `TEXT`, Optional)
+  - `estimated_minute` (Type: `INTEGER`, Optional)
+  - `task_date` (Type: `DATE`, Optional)
+  - `user_id` (Type: `UUID`): This will store the `user_id` associated with the integration key.
+
+### 1.3. RLS (Row Level Security) on `tasks` Table
+
+- For the RLS test, ensure RLS is enabled for the `tasks` table.
+- Create a policy that restricts access based on `user_id`. A common policy would be:
+
+  ```sql
+  ALTER TABLE tasks ENABLE ROW LEVEL SECURITY;
+
+  CREATE POLICY "Users can manage their own tasks"
+  ON tasks
+  FOR ALL
+  USING (auth.uid() = user_id)
+  WITH CHECK (auth.uid() = user_id);
+  ```
+
+  _Note: This policy assumes `auth.uid()` will correctly resolve to the `user_id` set in the JWT generated by the function._
+
+### 1.4. Environment Variables for the Edge Function
+
+Ensure the following environment variables are set for your `task-management` Supabase function (either locally via `.env` file if using `supabase start`, or in the Supabase project settings):
+
+- `SUPABASE_URL`: Your project's Supabase URL.
+- `SUPABASE_ANON_KEY`: Your project's anon key.
+- `SUPABASE_SERVICE_ROLE_KEY`: Your project's service role key.
+- `SUPABASE_JWT_SECRET`: A strong secret string used to sign the JWTs. This **must** be the same secret your Supabase project uses for its JWT verification. You can find this in your Supabase project's JWT settings.
+
+## 2. Testing Scenarios
+
+Use a tool like `curl` or Postman to make requests to the edge function. The default local URL is `http://127.0.0.1:54321/functions/v1/task-management`.
+
+### 2.1. Success Case
+
+- **Action**: Call the function with a valid `x-integration-id` (that is active) and valid JSON task data.
+  ```bash
+  curl -i --location --request POST 'http://127.0.0.1:54321/functions/v1/task-management' \
+  --header 'x-integration-id: test-integration-key-active' \
+  --header 'Content-Type: application/json' \
+  --data '{
+      "title": "My Test Task via Integration",
+      "description": "This is a task created successfully.",
+      "estimated_minute": 60
+  }'
+  ```
+- **Expected Outcome**:
+  - HTTP Status Code: `200 OK` (or `201 Created` if you've customized it, but the current code returns 200).
+  - Response Body: JSON similar to `{"message":"タスクが正常に作成されました","task":{...}}` where `task` contains the created task data, including its `id` and the correct `user_id`.
+- **Verification**:
+  - Check the `tasks` table in your Supabase project.
+  - A new task should be created with the details provided.
+  - The `user_id` of the new task **must** match the `user_id` associated with `test-integration-key-active` in your `integration_keys` table.
+
+### 2.2. Error Cases
+
+#### 2.2.1. Missing `x-integration-id` Header
+
+- **Action**: Call the function without the `x-integration-id` header.
+  ```bash
+  curl -i --location --request POST 'http://127.0.0.1:54321/functions/v1/task-management' \
+  --header 'Content-Type: application/json' \
+  --data '{"title":"Task missing header"}'
+  ```
+- **Expected Outcome**:
+  - HTTP Status Code: `400 Bad Request`.
+  - Response Body: `{"error":"x-integration-id header is missing"}`.
+
+#### 2.2.2. Non-existent `x-integration-id`
+
+- **Action**: Call the function with an `x-integration-id` that is not in the `integration_keys` table.
+  ```bash
+  curl -i --location --request POST 'http://127.0.0.1:54321/functions/v1/task-management' \
+  --header 'x-integration-id: non-existent-key' \
+  --header 'Content-Type: application/json' \
+  --data '{"title":"Task with non-existent key"}'
+  ```
+- **Expected Outcome**:
+  - HTTP Status Code: `404 Not Found`.
+  - Response Body: `{"error":"Integration key not found."}`.
+
+#### 2.2.3. Inactive `x-integration-id`
+
+- **Action**: Call the function with an `x-integration-id` that is marked `is_active = false`.
+  ```bash
+  curl -i --location --request POST 'http://127.0.0.1:54321/functions/v1/task-management' \
+  --header 'x-integration-id: test-integration-key-inactive' \
+  --header 'Content-Type: application/json' \
+  --data '{"title":"Task with inactive key"}'
+  ```
+- **Expected Outcome**:
+  - HTTP Status Code: `403 Forbidden`.
+  - Response Body: `{"error":"Integration key is inactive."}`.
+
+#### 2.2.4. Invalid Task Data
+
+- **Action**: Call the function with invalid task data (e.g., missing title).
+  ```bash
+  curl -i --location --request POST 'http://127.0.0.1:54321/functions/v1/task-management' \
+  --header 'x-integration-id: test-integration-key-active' \
+  --header 'Content-Type: application/json' \
+  --data '{"description":"Task missing title"}'
+  ```
+- **Expected Outcome**:
+  - HTTP Status Code: `400 Bad Request`.
+  - Response Body: `{"error":"Invalid task data","details":["タイトルは必須です"]}`.
+
+#### 2.2.5. Missing Environment Variable (Conceptual)
+
+- **Action**: This is harder to test directly with `curl` without modifying the function's deployment environment. If you were to temporarily unset `SUPABASE_JWT_SECRET` (or any of the other required env vars like `SUPABASE_URL`, `SUPABASE_ANON_KEY`, `SUPABASE_SERVICE_ROLE_KEY`) for the function and then call it:
+  ```bash
+  # Assuming SUPABASE_JWT_SECRET is unset for the function's environment
+  curl -i --location --request POST 'http://127.0.0.1:54321/functions/v1/task-management' \
+  --header 'x-integration-id: test-integration-key-active' \
+  --header 'Content-Type: application/json' \
+  --data '{"title":"Test Env Var Missing"}'
+  ```
+- **Expected Outcome**:
+  - HTTP Status Code: `500 Internal Server Error`.
+  - Response Body: `{"error":"Server configuration error."}`.
+  - Server-side logs for the function should indicate which variable was missing (e.g., "Missing one or more required environment variables...").
+
+### 2.3. RLS Test (Conceptual & Practical)
+
+This tests if the JWT generated by the function correctly assumes the `user_id` for RLS policies on the `tasks` table.
+
+- **Prerequisite**: Ensure RLS policy from section 1.3 is active.
+
+- **Scenario 1: Task `user_id` matches JWT `sub` (Implicit)**
+
+  - This is covered by the **Success Case (2.1)**. The `newTask` object in the function uses `user_id: taskData.user_id || actualUserId`. If `taskData.user_id` is NOT provided in the request body, `actualUserId` (from the integration key) is used. The JWT's `sub` claim is set to this `actualUserId`. RLS should allow the insert because `auth.uid()` (derived from the JWT `sub`) will match `newTask.user_id`.
+
+- **Scenario 2: Attempt to set `taskData.user_id` to a different user (if allowed by function logic)**
+
+  - The current function logic: `user_id: taskData.user_id || actualUserId`. This means if `taskData.user_id` _is_ provided in the request, it will take precedence _before_ being inserted. The JWT, however, will still be generated for `actualUserId` (the one from the integration key).
+  - **Action**: Send a request where `taskData.user_id` is a valid UUID of a _different_ user than the one associated with `test-integration-key-active`.
+    ```bash
+    # Assume 'other-user-uuid' is a valid UUID of a user who is NOT associated with 'test-integration-key-active'
+    curl -i --location --request POST 'http://127.0.0.1:54321/functions/v1/task-management' \
+    --header 'x-integration-id: test-integration-key-active' \
+    --header 'Content-Type: application/json' \
+    --data '{
+        "title": "RLS Test Task - Mismatched UserID",
+        "user_id": "other-user-uuid"
+    }'
+    ```
+  - **Expected Outcome**:
+    - HTTP Status Code: `400 Bad Request` (This is what the current code returns on Supabase insert errors, which an RLS violation would cause).
+    - Response Body: `{"error":"タスクの保存に失敗しました", "details":"..."}`. The details might contain "new row violates row-level security policy for table \"tasks\"" or similar.
+  - **Verification**:
+
+    - The task should NOT be created in the `tasks` table.
+    - This confirms that even if the function logic _could_ try to set a different `user_id`, the RLS policy enforced by Supabase (using the JWT's `auth.uid()`) prevents it.
+
+  - **Note on `taskData.user_id`**: The current function allows `taskData.user_id` to be optionally passed. If the intention is that the `x-integration-id` _solely_ dictates the `user_id`, then the function logic should be changed to ignore any `user_id` in `taskData` and always use `actualUserId`. The RLS policy, however, provides a strong safeguard.
+
+## 3. Cleanup
+
+- Remember to remove or deactivate test data (integration keys, tasks) as needed after testing.
+- Revert any temporary changes to environment variables.
+
+```
+
+```
diff --git a/supabase/functions/task-management/index.test.ts b/supabase/functions/task-management/index.test.ts
@@ -0,0 +1,178 @@
+import {
+  assert,
+  assertEquals,
+  assertExists,
+  assertObjectMatch,
+} from "https://deno.land/std@0.192.0/testing/asserts.ts"; // Using a specific version for stability
+import * as djwt from "https://deno.land/x/djwt@v2.8/mod.ts";
+// Assuming the createToken function is exported from index.ts or can be extracted/adapted
+// For this test, let's copy a simplified version of createToken here or make it accessible.
+
+// Simplified/adapted createToken for testing.
+// In a real scenario, you'd import this from your actual index.ts.
+// To make this self-contained for the tool, I'm redefining it.
+// IMPORTANT: This definition MUST match the one in index.ts for the test to be valid.
+async function createTokenForTest(
+  userId: string,
+  currentJwtSecret: string,
+  currentSupabaseUrl: string,
+) {
+  const payload = {
+    sub: userId,
+    role: "authenticated",
+    aud: "authenticated",
+    iss: currentSupabaseUrl,
+    iat: Math.floor(Date.now() / 1000),
+    exp: Math.floor(Date.now() / 1000) + 3600, // 1 hour expiration
+  };
+
+  const secretKeyData = new TextEncoder().encode(currentJwtSecret);
+  const key = await crypto.subtle.importKey(
+    "raw",
+    secretKeyData,
+    { name: "HMAC", hash: "SHA-256" },
+    false,
+    ["sign", "verify"], // Ensure "verify" is also here if using the same key for djwt.verify
+  );
+  return await djwt.create({ alg: "HS256", typ: "JWT" }, payload, key);
+}
+
+// Helper to import a key for djwt.verify, similar to how createToken does for signing
+async function importKeyForVerification(jwtSecret: string) {
+  const secretKeyData = new TextEncoder().encode(jwtSecret);
+  return await crypto.subtle.importKey(
+    "raw",
+    secretKeyData,
+    { name: "HMAC", hash: "SHA-256" },
+    false,
+    ["verify"],
+  );
+}
+
+Deno.test("createToken generates a valid JWT with correct claims", async () => {
+  const mockUserId = "12345678-1234-1234-1234-1234567890ab";
+  const mockSupabaseUrl = "http://localhost:54321";
+  const mockJwtSecret = "test-super-secret-jwt-token-for-testing"; // Must be strong enough for HS256
+
+  // Store original Deno.env.get and replace it
+  const originalEnvGet = Deno.env.get;
+  const mockEnv: Record<string, string> = {
+    SUPABASE_URL: mockSupabaseUrl,
+    SUPABASE_JWT_SECRET: mockJwtSecret,
+  };
+  Deno.env.get = (key: string) => mockEnv[key] || undefined;
+
+  let token: string | undefined;
+  let error: Error | undefined;
+
+  try {
+    // In a real test, you'd call the original createToken function from index.ts
+    // For now, calling the adapted version:
+    token = await createTokenForTest(
+      mockUserId,
+      mockJwtSecret,
+      mockSupabaseUrl,
+    );
+  } catch (e) {
+    error = e;
+  } finally {
+    // Restore original Deno.env.get
+    Deno.env.get = originalEnvGet;
+  }
+
+  assert(!error, `Token generation failed: ${error?.message}`);
+  assertExists(token, "Token was not generated.");
+
+  // Verify the token
+  let decodedPayload: djwt.Payload | undefined;
+  let verificationError: Error | undefined;
+  try {
+    const key = await importKeyForVerification(mockJwtSecret);
+    decodedPayload = await djwt.verify(token!, key);
+  } catch (e) {
+    verificationError = e;
+  }
+
+  assert(
+    !verificationError,
+    `Token verification failed: ${verificationError?.message}`,
+  );
+  assertExists(decodedPayload, "Token payload could not be decoded.");
+
+  // Check standard claims
+  assertEquals(
+    decodedPayload.sub,
+    mockUserId,
+    "Subject claim (sub) is incorrect.",
+  );
+  assertEquals(
+    decodedPayload.iss,
+    mockSupabaseUrl,
+    "Issuer claim (iss) is incorrect.",
+  );
+  assertEquals(
+    decodedPayload.aud,
+    "authenticated",
+    "Audience claim (aud) is incorrect.",
+  );
+  assertEquals(
+    decodedPayload.role,
+    "authenticated",
+    "Role claim is incorrect.",
+  );
+
+  // Check time-based claims (iat, exp)
+  assertExists(decodedPayload.iat, "IssuedAt claim (iat) is missing.");
+  assertExists(decodedPayload.exp, "Expiration claim (exp) is missing.");
+  assert(typeof decodedPayload.iat === "number", "iat should be a number.");
+  assert(typeof decodedPayload.exp === "number", "exp should be a number.");
+  assert(decodedPayload.exp > decodedPayload.iat, "exp should be after iat.");
+
+  // Check if iat is recent (e.g., within the last 5 minutes)
+  const nowInSeconds = Math.floor(Date.now() / 1000);
+  assert(
+    decodedPayload.iat <= nowInSeconds &&
+      decodedPayload.iat > nowInSeconds - 300,
+    "iat is not recent.",
+  );
+  // Check if exp is approximately 1 hour from iat
+  assertEquals(
+    decodedPayload.exp,
+    decodedPayload.iat + 3600,
+    "exp is not 1 hour after iat.",
+  );
+});
+
+Deno.test(
+  "createToken (adapted) throws error if JWT secret is empty or too weak (conceptual)",
+  async () => {
+    // This specific test is harder to make pass deterministically with createTokenForTest
+    // because crypto.subtle.importKey itself will throw an error for weak keys
+    // before djwt.create even gets called with an empty secret.
+    // djwt's own internal checks might also fire.
+
+    // The main function (index.ts) has an upfront check for SUPABASE_JWT_SECRET.
+    // This test case is more about the robustness of crypto APIs.
+
+    const mockUserId = "test-user-id";
+    const mockSupabaseUrl = "http://localhost:8000";
+    const weakSecret = ""; // Empty secret
+
+    let error: Error | undefined;
+    try {
+      // We are calling createTokenForTest directly, which doesn't have the Deno.env.get('SUPABASE_JWT_SECRET') check.
+      // The error will likely come from crypto.subtle.importKey.
+      await createTokenForTest(mockUserId, weakSecret, mockSupabaseUrl);
+    } catch (e) {
+      error = e;
+    }
+
+    assertExists(
+      error,
+      "createTokenForTest should throw an error with an empty secret.",
+    );
+    // The error message might vary: "Key length is zero" or similar from crypto.subtle, or from djwt.
+    // For now, just checking an error is thrown is sufficient for this conceptual test.
+    console.log(`(Conceptual test) Error for empty secret: ${error?.message}`);
+  },
+);
diff --git a/supabase/functions/task-management/index.ts b/supabase/functions/task-management/index.ts
