Upgrade StorageFeature request: Secure remote Zotero Connector access over LAN/VPN
I would like to ask whether the maintainers would accept an implementation for securely connecting Zotero Connectors on other trusted devices to one running Zotero desktop instance over a LAN or VPN.
Use case: Zotero runs continuously on one workstation/server, while browsers on a laptop, Chromebook, or another trusted device save through that same Zotero instance. The Connector already has the configurable `connector.url` preference, but Zotero's connector HTTP server intentionally binds only to loopback and validates the `Host` header as localhost.
There is an older discussion with the same basic use case, where the suggested workaround was a reverse proxy:
https://forums.zotero.org/discussion/95571/httpserver-only-works-on-localhost
A reverse proxy works, but every user has to construct the security boundary themselves. Exposing the connector API without authentication would obviously be unsafe.
Would the project be open to an opt-in design such as:
- Default remains loopback-only, preserving current behavior.
- Optional configurable bind address, intended for trusted LAN/VPN interfaces.
- Required authentication token whenever the bind address is not loopback.
- Optional IP/CIDR allowlist.
- Existing Host/DNS-rebinding protections retained or adapted rather than removed.
- Clear warning that this is not intended for direct public-internet exposure.
Alternatively, would maintainers prefer keeping Zotero loopback-only and officially documenting a local reverse-proxy/tunnel pattern?
Before attempting a patch, I would like to confirm whether either direction is acceptable and what security/API design the maintainers would prefer.
Use case: Zotero runs continuously on one workstation/server, while browsers on a laptop, Chromebook, or another trusted device save through that same Zotero instance. The Connector already has the configurable `connector.url` preference, but Zotero's connector HTTP server intentionally binds only to loopback and validates the `Host` header as localhost.
There is an older discussion with the same basic use case, where the suggested workaround was a reverse proxy:
https://forums.zotero.org/discussion/95571/httpserver-only-works-on-localhost
A reverse proxy works, but every user has to construct the security boundary themselves. Exposing the connector API without authentication would obviously be unsafe.
Would the project be open to an opt-in design such as:
- Default remains loopback-only, preserving current behavior.
- Optional configurable bind address, intended for trusted LAN/VPN interfaces.
- Required authentication token whenever the bind address is not loopback.
- Optional IP/CIDR allowlist.
- Existing Host/DNS-rebinding protections retained or adapted rather than removed.
- Clear warning that this is not intended for direct public-internet exposure.
Alternatively, would maintainers prefer keeping Zotero loopback-only and officially documenting a local reverse-proxy/tunnel pattern?
Before attempting a patch, I would like to confirm whether either direction is acceptable and what security/API design the maintainers would prefer.