Add password-protected POST endpoint for updating existing files by ID

[Copilot]

Overview

This PR implements a new password-protected POST endpoint that allows updating existing JSON files by providing their ID and the correct password. It also modifies the GET endpoint to indicate password protection status.

Changes

New Endpoint: POST /api/v2/post/:id

Allows updating an existing file when the correct password is provided:

# Update a password-protected file
curl -X POST https://json.openpatch.org/api/v2/post/abc123 \
  -H "Content-Type: application/json" \
  -d '{"data": "updated content", "password": "mySecret"}'

Validation logic:

• File must exist (returns 404 if not found)
• File must be password-protected (returns 403 if no password stored)
• Request must include password (returns 401 if missing)
• Password must match stored password (returns 401 if incorrect)
• File is replaced with new content on successful validation

Modified GET Endpoint: GET /api/v2/:key

The GET endpoint now replaces the password value with a boolean indicator:

// Stored file
{"data": "content", "password": "secret"}

// GET response (password replaced with boolean)
{"data": "content", "password": true}

For files without passwords, the password field is not included:

// Stored file
{"data": "content"}

// GET response (no password field)
{"data": "content"}

Password Protection Flow

1. Create a file with optional password:

POST /api/v2/post/
{"data": "content", "password": "secret123"}

2. Read the file (password shown as boolean):

GET /api/v2/abc123
# Returns: {"data": "content", "password": true}

3. Update with correct password:

POST /api/v2/post/abc123
{"data": "new content", "password": "secret123"}

Security Improvements

Added input validation to prevent path traversal attacks in both GET and POST endpoints:

• Rejects keys/IDs containing /, \, or ..
• Protects against both direct and URL-encoded attack attempts

Documentation

Updated README.md with comprehensive API documentation including:

• Usage examples for all endpoints
• Request/response formats
• Error codes and their meanings
• Security notes about password handling

Testing

Manually tested all scenarios:

• ✅ Create files with/without passwords
• ✅ GET replaces password field with boolean true for password-protected files
• ✅ GET omits password field for non-password-protected files
• ✅ POST with ID validates passwords correctly
• ✅ Appropriate HTTP status codes for all error cases
• ✅ Path traversal attempts blocked

Breaking Changes

The GET endpoint now returns application/json and always parses JSON files. The password field is replaced with a boolean value (true) when present, instead of being removed entirely.

Original prompt

There should be another post endpoint with a given id. This endpoint should be password protected. The password is saved in the json file under the key password. On get the password should not be served. Only if the password matches the one in the json file, the file should be replaced with the new one. Please update the documentation accordingly.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[mikebarkmin]

@copilot there needs to be no backward-compatability. Also send on get if the file is password protected. Maybe replace password with hasPassword boolean instead of deleting it. Or just password boolean without renaming the field.

[Copilot]

@copilot there needs to be no backward-compatability. Also send on get if the file is password protected. Maybe replace password with hasPassword boolean instead of deleting it. Or just password boole...

Done. Removed backward compatibility for non-JSON files and changed GET endpoint to replace the password value with boolean true when a file is password-protected. Files without passwords don't include the password field at all. Changes committed in 6f3b9c5.