-
Notifications
You must be signed in to change notification settings - Fork 35
Description
KOInsight currently ships with no built-in authentication on the web UI.
When self-hosted on a public VPS, this makes the app effectively unusable unless it’s hidden behind network-level controls.
Adding HTTP Basic Auth at the reverse proxy level (Caddy / Nginx) does secure the UI — but it breaks the KOReader plugin, which cannot authenticate against Basic Auth–protected endpoints.
This creates an all-or-nothing situation:
- Public VPS → insecure
- Reverse-proxy auth → plugin stops working
KOInsight is excellent, but without built-in authentication it cannot be safely self-hosted on a public server. Reverse-proxy auth breaks the plugin, leaving no viable secure deployment path.
Adding native auth would immediately unlock real-world VPS deployments and make KOInsight production-ready.
Happy to test or help validate any auth approach (password, token, header-based) if this moves forward.
Requested Feature
Add native application-level authentication to KOInsight, for example:
- Username/password login for the web UI
- Token-based auth or API key support for the KOReader plugin
- Optional ability to disable auth for local-only deployments
The key requirement is auth handled inside the app, not delegated to the reverse proxy.
Why This Matters
Self-hosting on a public VPS is a completely normal deployment model, but exposing reading history, highlights, and metadata without auth is a non-starter. This blocks adoption for anyone who isn’t running KOInsight on a private LAN
Right now, KOInsight is functionally insecure by default when deployed publicly.
Suggested Implementation (Non-Prescriptive)
Any of the following would solve the problem:
- Simple username/password auth stored locally
- API tokens scoped for plugin access
- Header-based auth support (e.g. Authorisation: Bearer)
- Env-based credentials for containerised deployments
The exact approach is up to you — but some form of first-class auth is essential.