877021ff20
1. Trips TLS: Removed all ssl CERT_NONE / check_hostname=False from 5 external HTTPS call sites (OpenAI, Gemini, Google Places, Geocode). All external calls now use default TLS verification. 2. Internal CORS: Removed permissive cors() from inventory and budget. Both are internal services accessed only via gateway. 3. App visibility: Documented as cosmetic-only in layout.server.ts. Nav hiding is intentional UX, not access control. 4. Disconnect safety: Added confirm() dialog before service disconnect in Settings. Prevents accidental disconnects. 5. Inventory cleanup: Removed stale /test startup log message. Replaced with API key status indicator. 6. Frontend deps: 4 low-severity cookie vulnerabilities in @sveltejs/kit. Fix requires breaking downgrade to kit@0.0.30 — not safe. Documented.
64 lines
2.9 KiB
Plaintext
64 lines
2.9 KiB
Plaintext
Work in the `platform` repo and start from the current code state, not prior summaries.
|
|
|
|
Use Gitea issues and the current repo as source of truth, but re-verify everything before editing.
|
|
|
|
Current remaining code issues to address:
|
|
|
|
1. Trips TLS handling
|
|
- `services/trips/server.py` still contains many outbound HTTPS calls that explicitly disable TLS verification with:
|
|
- `ssl_context.check_hostname = False`
|
|
- `ssl_context.verify_mode = ssl.CERT_NONE`
|
|
- This appears in Google Places, Immich, Google Photos, and related external fetch flows.
|
|
- Fix the remaining unsafe TLS behavior by using default certificate and hostname verification wherever possible.
|
|
- If any exception is truly required, document it narrowly and do not leave broad `CERT_NONE` behavior in place.
|
|
|
|
2. Internal service CORS cleanup
|
|
- `services/inventory/server.js` still uses `app.use(cors())`
|
|
- `services/budget/server.js` still uses `app.use(cors())`
|
|
- These services are intended to be internal / gateway-accessed / API-key protected.
|
|
- Remove permissive CORS or restrict it explicitly to the minimum actually required.
|
|
|
|
3. App visibility vs real authorization
|
|
- `frontend-v2/src/routes/(app)/+layout.server.ts` uses a hardcoded `hiddenByUser` map.
|
|
- This only hides nav items and does not block direct URL access.
|
|
- Re-check whether this behavior is intentional.
|
|
- If the hidden apps are meant to be cosmetic only, document that clearly.
|
|
- If they are meant to be actually inaccessible to some users, enforce route-level access control instead of nav hiding only.
|
|
|
|
4. Settings disconnect safety
|
|
- `frontend-v2/src/routes/(app)/settings/+page.svelte` still allows immediate disconnect without confirmation.
|
|
- This already caused a real user issue.
|
|
- Add a confirmation step or another guardrail so users do not accidentally disconnect critical services.
|
|
- Keep the UX minimal and production-appropriate.
|
|
|
|
5. Inventory stale debug/test residue
|
|
- `services/inventory/server.js` still contains a stale `// Test endpoint` comment
|
|
- Startup logs still mention `/test`
|
|
- Remove stale references so runtime output matches actual behavior.
|
|
|
|
6. Frontend dependency follow-up
|
|
- `frontend-v2` still has low-severity `npm audit` findings tied to older SvelteKit/cookie dependencies.
|
|
- Re-check current audit output before changing anything.
|
|
- If the upgrade is small and safe, fix it.
|
|
- If the upgrade is disruptive, document it honestly and do not overstate completion.
|
|
|
|
Constraints:
|
|
- Make minimal, production-oriented changes.
|
|
- Preserve unrelated user changes.
|
|
- Verify each fix directly after making it.
|
|
- Do not claim an issue is complete unless the current code actually supports that claim.
|
|
- Do not rotate or change admin credentials during this pass.
|
|
|
|
After each issue-sized change:
|
|
- comment on the relevant Gitea issue with:
|
|
- what changed
|
|
- files touched
|
|
- verification performed
|
|
- what remains
|
|
|
|
Final output format:
|
|
- `Completed:`
|
|
- `Partial:`
|
|
- `Blocked:`
|
|
- `Manual ops actions:`
|