32 lines
2.5 KiB
Markdown
32 lines
2.5 KiB
Markdown
Reference issues or pull requests here (e.g., "Closes #123")
|
|
# Secure Background Workers with Strict User Ownership Checks
|
|
|
|
## Background
|
|
The `potion-voice` microservice operates background SQS queue workers (`voice-synthsizer-job-handler` and `voice-cloning-job-handler`) that process long-running speech synthesis and voice cloning tasks. Jobs ingested from SQS queues contain user identifiers (`userId`) alongside record keys (`salutationId`, `userAudioProfileId`, `recordingId`).
|
|
|
|
A recent security audit flagged that database queries across the worker handlers and database services fetch and update MongoDB documents using document IDs only, without verifying records belong to the `userId` associated with the job.
|
|
|
|
## Objective
|
|
Update the worker handlers (`voice-synthsizer-job-handler/index.js`, `voice-cloning-job-handler/index.js`) and database models/services (`userAudioProfileService`, `voiceCloningService`, and related Mongoose models) to enforce strict user ownership validation.
|
|
|
|
## Requirements
|
|
|
|
1. **User Boundaries Scoping across Database Queries**:
|
|
- Ensure all MongoDB CRUD operations strictly scope queries by `userId` (e.g. matching both `_id` and `userId`).
|
|
- Prevent unauthorized user boundry data access or changes when job payloads contain mismatched document IDs and `userId` values.
|
|
|
|
2. **Asynchronous Execution Order Integrity**:
|
|
- Maintain strict execution order while working through database document dependencies.
|
|
- Do not query secondary dependent models (such as `Recording`) using uninitialized or undefined variables before primary parent models (such as `Salutation`) have finished loading.
|
|
|
|
3. **Queue Message Lifecycle & Reliability**:
|
|
- Ensure SQS messages are deleted from the queue (`deleteMessageFromSQS`) **only after** all pipeline operations—including audio rendering, Python script execution, and S3 asset uploads—have completed successfully.
|
|
- Preserving queue retry capabilities on processing failures is critical to prevent silent job loss.
|
|
|
|
4. **Error Handling & Exception Recovery**:
|
|
- If a user authorization check fails or a document is missing for the given `userId`, handle the failure gracefully.
|
|
- Ensure `catch` blocks handle errors cleanly without throwing unhandled secondary Promise rejections.
|
|
|
|
## Verification
|
|
Ensure the worker pipeline executes cleanly without syntax errors, runtime `ReferenceError`s, or unhandled Promise rejections, and verify that jobs attempting cross-account access fail safely without mutating unauthorized records.
|