Some checks are pending
Go Benchmark / Performance Regression Check (push) Waiting to run
Cerberus Integration / Cerberus Security Stack Integration (push) Waiting to run
Upload Coverage to Codecov / Backend Codecov Upload (push) Waiting to run
Upload Coverage to Codecov / Frontend Codecov Upload (push) Waiting to run
CodeQL - Analyze / CodeQL analysis (go) (push) Waiting to run
CodeQL - Analyze / CodeQL analysis (javascript-typescript) (push) Waiting to run
CrowdSec Integration / CrowdSec Bouncer Integration (push) Waiting to run
Docker Build, Publish & Test / build-and-push (push) Waiting to run
Docker Build, Publish & Test / Security Scan PR Image (push) Blocked by required conditions
Quality Checks / Auth Route Protection Contract (push) Waiting to run
Quality Checks / Codecov Trigger/Comment Parity Guard (push) Waiting to run
Quality Checks / Backend (Go) (push) Waiting to run
Quality Checks / Frontend (React) (push) Waiting to run
Rate Limit integration / Rate Limiting Integration (push) Waiting to run
Security Scan (PR) / Trivy Binary Scan (push) Waiting to run
Supply Chain Verification (PR) / Verify Supply Chain (push) Waiting to run
WAF integration / Coraza WAF Integration (push) Waiting to run
94 lines
3.9 KiB
Markdown
Executable File
94 lines
3.9 KiB
Markdown
Executable File
---
|
|
title: "Manual Test Plan - Issue #825: HTTP Login from Private Network IPs"
|
|
status: Open
|
|
priority: High
|
|
assignee: QA
|
|
labels: testing, backend, frontend, security
|
|
---
|
|
|
|
# Test Objective
|
|
|
|
Confirm that users can log in to Charon over HTTP when accessing from a private network IP (e.g., `192.168.x.x:8080`), and that HTTPS and localhost login paths remain unaffected.
|
|
|
|
# Scope
|
|
|
|
- In scope: Auth cookie behavior across HTTP/HTTPS, private IPs, localhost, and port remapping. Session persistence and the Bearer token fallback.
|
|
- Out of scope: Setup wizard UI styling, non-auth API endpoints, Caddy proxy configuration changes.
|
|
|
|
# Prerequisites
|
|
|
|
- Fresh Charon instance (no existing users in the database).
|
|
- Access to a machine on the same LAN (or the host machine itself using its LAN IP).
|
|
- A second device or browser for cross-tab and LAN IP tests.
|
|
- For HTTPS scenarios: a reverse proxy (Caddy or nginx) with TLS termination in front of Charon.
|
|
- Browser DevTools available to inspect cookies and network requests.
|
|
|
|
# Manual Scenarios
|
|
|
|
## 1) Fresh install login over HTTP from LAN IP (original bug)
|
|
|
|
- [ ] Deploy a fresh Charon instance with an empty database.
|
|
- [ ] From another machine on the LAN, open `http://<LAN-IP>:8080` (e.g., `http://192.168.1.50:8080`).
|
|
- [ ] Complete the setup wizard and create an admin user.
|
|
- [ ] Log in with the credentials you just created.
|
|
- [ ] **Expected**: Login succeeds. You are redirected to the dashboard. No "unauthorized" flash or redirect back to login.
|
|
- [ ] Open DevTools > Network tab. Confirm `/api/auth/me` returns `200`.
|
|
- [ ] Open DevTools > Application > Cookies. Confirm the auth cookie has `Secure: false`.
|
|
|
|
## 2) Login over HTTPS via reverse proxy
|
|
|
|
- [ ] Configure a reverse proxy (Caddy or nginx) with TLS termination pointing to Charon.
|
|
- [ ] Open `https://<your-domain-or-ip>` in the browser.
|
|
- [ ] Log in with valid credentials.
|
|
- [ ] **Expected**: Login succeeds. Redirected to the dashboard.
|
|
- [ ] Open DevTools > Application > Cookies. Confirm the auth cookie has `Secure: true`.
|
|
|
|
## 3) Login from localhost over HTTP (regression check)
|
|
|
|
- [ ] On the machine running Charon, open `http://localhost:8080`.
|
|
- [ ] Log in with valid credentials.
|
|
- [ ] **Expected**: Login succeeds. This is existing behavior and must not regress.
|
|
|
|
## 4) Session persistence after page refresh
|
|
|
|
- [ ] Log in successfully via any access method.
|
|
- [ ] Press F5 (hard refresh).
|
|
- [ ] **Expected**: You remain logged in. The dashboard loads without a redirect to the login page.
|
|
|
|
## 5) Multiple browser tabs
|
|
|
|
- [ ] Log in on Tab 1.
|
|
- [ ] Open a new Tab 2 and navigate to the same Charon URL.
|
|
- [ ] **Expected**: Tab 2 loads the dashboard immediately without prompting for login.
|
|
|
|
## 6) Logout and re-login
|
|
|
|
- [ ] Log in, then click Logout.
|
|
- [ ] **Expected**: Redirected to the login page.
|
|
- [ ] Log in again with the same credentials.
|
|
- [ ] **Expected**: Login succeeds with a clean session. No stale session errors.
|
|
|
|
## 7) Port remapping scenario
|
|
|
|
- [ ] Run Charon with Docker port mappings: `-p 82:80 -p 445:443 -p 8080:8080`.
|
|
- [ ] Access Charon on `http://<LAN-IP>:8080`.
|
|
- [ ] Log in with valid credentials.
|
|
- [ ] **Expected**: Login succeeds on the remapped port.
|
|
- [ ] If a reverse proxy is available, repeat via `https://<LAN-IP>:445`.
|
|
- [ ] **Expected**: Login succeeds with `Secure: true` on the cookie.
|
|
|
|
# Expected Results
|
|
|
|
- Login over HTTP from a private network IP works on fresh install.
|
|
- Cookie `Secure` flag is `false` for HTTP and `true` for HTTPS.
|
|
- Localhost login remains functional.
|
|
- Sessions survive page refreshes and work across tabs.
|
|
- Logout cleanly destroys the session, and re-login creates a new one.
|
|
- Port remapping does not break authentication.
|
|
|
|
# Regression Checks
|
|
|
|
- [ ] Confirm no changes to login behavior when accessing via `localhost` or `127.0.0.1`.
|
|
- [ ] Confirm HTTPS connections still set `Secure: true` on the auth cookie.
|
|
- [ ] Confirm the Bearer token header fallback does not interfere when cookies are working normally.
|