[Bug] Repeated prompts to re-enter PAT and API_SECRET; values not persisted after Docker restart

[raphaelbahat]

平台

Web

后端

Docker / GHCR 后端

Bug 描述

GithubStarsManager repeatedly prompts to re-enter the GitHub Personal Access Token (PAT) and the value of API_SECRET. These values do not appear to persist: after some time and after a Docker restart the app requests them again.

Reproduction steps:

1. Configure the app with a valid PAT and API_SECRET and run using the Docker backend.
2. Use the app normally, then either restart the Docker container or wait some time (several hours / overnight).
3. Open the app and observe that it prompts to re-enter the PAT and API_SECRET.

Observed frequency: Intermittent but reproducible after Docker restart.
App version: Unknown (running via Docker)

附加信息

Additional context: this happens when running the Docker / GHCR backend. The credentials (PAT and API_SECRET) are entered and the app appears to work, but after a restart or after some time the credentials are lost and the UI prompts for them again. Possible areas to check: how credentials are stored/persisted (files, environment variables, Docker volumes), and whether Docker image or container recreation clears them. No logs attached yet.

日志

No response

截图

No response

视频

No response

[AmintaCCCP]

Hi @raphaelbahat, thanks for the report. To narrow this down, a few quick questions:

1. Same browser/machine every time, or do you sometimes use a different browser / Incognito / another device?
2. How do you run it — docker compose up -d, or docker run? If the latter, do you mount a volume (-v ...:/app/data)?
3. After reopening the tab, does the PAT prompt also appear? (API_SECRET always clears on tab close by design.)
4. Does the login screen appear while the tab stays open, or only after reopening the browser?
5. Could you run docker volume ls and share the backend logs (docker logs <container>) — looking for Generated new encryption key or auth is disabled?

[raphaelbahat]

Hi @raphaelbahat, thanks for the report. To narrow this down, a few quick questions:

1. Same browser/machine every time, or do you sometimes use a different browser / Incognito / another device?
2. How do you run it — docker compose up -d, or docker run? If the latter, do you mount a volume (-v ...:/app/data)?
3. After reopening the tab, does the PAT prompt also appear? (API_SECRET always clears on tab close by design.)
4. Does the login screen appear while the tab stays open, or only after reopening the browser?
5. Could you run docker volume ls and share the backend logs (docker logs <container>) — looking for Generated new encryption key or auth is disabled?

Hi.

1. I'm using the same machine and browser every time.
2. Running via docker compose up -d.
   My docker-compose.yaml file content is:

name: github-stars-manager

services:
  frontend:
    image: ghcr.io/amintacccp/github-stars-manager-frontend:${FRONTEND_IMAGE_TAG:-latest}
    container_name: github-stars-manager-frontend
    ports:
      - "127.0.0.1:8081:80"
    depends_on:
      - backend
    env_file: [.env]
    restart: unless-stopped
    labels:
      dockhand.update: "true"
      dockhand.hidden: "false"
      dockhand.notify: "true"

  backend:
    image: ghcr.io/amintacccp/github-stars-manager-server:${BACKEND_IMAGE_TAG:-latest}
    container_name: github-stars-manager-backend
    expose:
      - "3000"
    env_file: [.env]
    volumes:
      - backend-data:/app/data
    restart: unless-stopped
    labels:
      dockhand.update: "true"
      dockhand.hidden: "false"
      dockhand.notify: "true"

volumes:
  backend-data:

3. The PAT prompt reappears after Docker or server restart or every few hours to days.
4. I'm not sure, but I think after closing the tab.
5. docker compose volumes outputs:

DRIVER    VOLUME NAME
local     github-stars-manager_backend-data

Both docker compose logs | grep -i 'Generated new encryption key' and docker compose logs | grep -i 'auth is disabled' output nothing (i.e., no results).

Also, since API_SECRET is always cleared on tab close by design, I'd like to propose persisting it in the database: it will make functionality much more seamless, easier, and less tedious from the user's perspective.

[AmintaCCCP]

Hi @raphaelbahat, thanks for the details — that is exactly what we needed. The good news: your Docker setup is not the problem. Your compose file, the backend-data volume, and the absence of Generated new encryption key / auth is disabled logs all confirm the backend is fine and your GitHub token has never been lost server-side.

Root cause (it was browser-side all along)

The credentials are stored in the browser, not in Docker:

• GitHub PAT: stored in the browser's IndexedDB through an asynchronous, debounced write. When you close the tab, the final write can be interrupted before it lands, so on the next open the stored snapshot has no credentials → the login screen appears. This matches the "intermittent but reproducible after closing the tab / restart" behaviour.
• API_SECRET: by design it was only kept in sessionStorage, which is wiped on every tab close. That is the "always re-entered" part.

What the fix (PR #260) does

1. Synchronous auth mirror (fixes the lost PAT). Your login state is now also written to a plain localStorage key immediately (no debounce), so even if the async IndexedDB write is interrupted, the app recovers the session from the mirror on next load. Persisted values still win over the mirror when both exist.
2. API_SECRET is now persisted (your request). It is no longer cleared on tab close — it is stored in IndexedDB (persist v10) and in the same localStorage mirror, so you enter it once per browser.
3. Cross-device session restore. A new POST /api/sync/auth endpoint lets a fresh browser/device that already knows the API_SECRET re-establish the GitHub session automatically (re-validated against the GitHub API before login). For security the endpoint only returns your GitHub token — never the API_SECRET.
4. Cleaner logout. Logging out now fully clears the mirror, the session cache, and the in-memory secret.

How to test the PR

GHCR images are only published from main / version tags (not from PRs), so you need to build from the PR code — but you can stay fully on docker compose up -d with a small compose override file (no manual docker build / tagging).

1. Get the PR code

git clone https://github.com/AmintaCCCP/GithubStarsManager.git
cd GithubStarsManager
git fetch origin pull/260/head:pr-260
git checkout pr-260

2. Create a tiny override file (so you don't have to edit the main compose)

# docker-compose.local.yml
services:
  frontend:
    build: .
    image: ghcr.io/amintacccp/github-stars-manager-frontend:pr260
  backend:
    build: ./server
    image: ghcr.io/amintacccp/github-stars-manager-server:pr260

3. Set the same keys you use today, then up

export API_SECRET=your-api-secret
export ENCRYPTION_KEY=your-encryption-key   # keep it identical to before

docker compose -f docker-compose.yml -f docker-compose.local.yml up -d --build

Compose builds both images from the PR code and starts the stack. ENCRYPTION_KEY must match what you used before so your existing backend-data volume (which holds your encrypted GitHub token) still decrypts.

Open http://127.0.0.1:8081 and sign in once with your PAT.

To switch back to the released latest images afterwards, just drop the override file and run docker compose up -d.

Test checklist

• Tab close: sign in, close the tab completely, reopen the app → still logged in, no PAT prompt.
• Browser restart: quit and relaunch the browser, reopen the app → still logged in.
• Container restart: docker compose restart → still logged in.
• Full recreate: docker compose down && docker compose up -d → still logged in (volume keeps the encrypted token).
• Time: leave it running for a while (or overnight) → no prompt when you return.
• New browser / Incognito: it will ask for API_SECRET once (this is expected — one-time bootstrap), then the GitHub session should restore automatically via /api/sync/auth.

If any step still shows a login prompt, please share: which step, the browser (Chrome/Edge/Firefox/Safari + version), and the docker compose logs output. That would help us pin down any remaining edge case before merge. Thanks again for the detailed report!