CORS implemented in a static manner: unable to configure on another machine

This commit is contained in:
aodulov
2025-10-15 13:45:36 +03:00
parent ea0e025b0e
commit 03d31011fd
18 changed files with 582 additions and 16 deletions

View 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.