CORS implemented in a static manner: unable to configure on another machine
This commit is contained in:
52
specs/008-deploy-to-hosting/plan.md
Normal file
52
specs/008-deploy-to-hosting/plan.md
Normal file
@@ -0,0 +1,52 @@
|
||||
# Implementation Plan: Deploy to Hosting
|
||||
|
||||
**Date**: 2025-10-15
|
||||
**Spec**: [spec.md](./spec.md)
|
||||
|
||||
## 1. Technical Context
|
||||
|
||||
This feature enables the application to be deployed to a public-facing host. The core of this work involves externalizing configuration from code to environment variables and ensuring the backend's Cross-Origin Resource Sharing (CORS) policy is configurable.
|
||||
|
||||
- **Backend**: The Node.js/Express backend will use the `cors` middleware to validate incoming request origins against a configurable whitelist provided by the `CORS_ORIGIN` environment variable.
|
||||
- **Frontend**: The React frontend will fetch the backend URL from a `REACT_APP_API_URL` environment variable, making it easy to target different backends.
|
||||
- **Deployment**: The root `docker-compose.yaml` will be modified to inject these environment variables into the respective containers using `env_file`.
|
||||
|
||||
## 2. Constitution Check
|
||||
|
||||
- [x] **I. Defined Technology Stack**: Adheres to Node.js, React, and Docker.
|
||||
- [x] **II. UI/UX Consistency**: No UI changes are required.
|
||||
- [x] **III. Container-First Development**: The solution is built entirely around enhancing the existing Docker-based workflow.
|
||||
- [x] **IV. Test-Driven Development (TDD)**: New tests will be required to validate the CORS configuration logic and error handling.
|
||||
- [x] **V. API-First Design**: No API changes are made, but the accessibility of the API is modified, which is consistent with this principle.
|
||||
|
||||
**Result**: All constitutional principles are upheld.
|
||||
|
||||
## 3. Implementation Phases
|
||||
|
||||
### Phase 0: Research & Decisions
|
||||
|
||||
Research focused on confirming the standard practices for configuration management in the existing tech stack.
|
||||
|
||||
- **Outcome**: All technical decisions have been documented.
|
||||
- **Artifact**: [research.md](./research.md)
|
||||
|
||||
### Phase 1: Design & Contracts
|
||||
|
||||
This phase defines the developer-facing instructions and confirms that no data or API contract changes are necessary.
|
||||
|
||||
- **Data Model**: No changes are required.
|
||||
- **Artifact**: [data-model.md](./data-model.md)
|
||||
- **API Contracts**: No changes are required.
|
||||
- **Artifact**: [contracts/README.md](./contracts/README.md)
|
||||
- **Developer Quickstart**: Instructions for configuring the environment for deployment have been created.
|
||||
- **Artifact**: [quickstart.md](./quickstart.md)
|
||||
|
||||
### Phase 2: Implementation Tasks
|
||||
|
||||
*(This section will be filled out by the `/speckit.tasks` command.)*
|
||||
|
||||
## 4. Validation Plan
|
||||
|
||||
- **Unit Tests**: Add backend tests to verify that the CORS middleware correctly allows whitelisted origins and rejects others.
|
||||
- **Integration Tests**: An E2E test will be created to simulate a deployment with a custom domain, ensuring the frontend can connect to the backend without CORS errors.
|
||||
- **Manual Tests**: Follow the [quickstart.md](./quickstart.md) guide to perform a full deployment and verify all functionality.
|
||||
Reference in New Issue
Block a user