Gandalf/sofarr
Public Access
0
0
Fork 0
Code Issues 1 Pull Requests Actions 1 Packages Projects Releases 59 Wiki Activity

BUG: Proxy routes only expose a subset of upstream APIs (not the full claimed surface) #67

New Issue
Closed
opened 2026-05-28 11:40:30 +01:00 by Gandalf · 1 comment
Gandalf commented 2026-05-28 11:40:30 +01:00
Owner
Copy Link
Copy Source

Description:

The proxy routes (/api/sonarr/*, /api/radarr/*, /api/sabnzbd/*, /api/emby/*, etc.) only implement a limited subset of the upstream service APIs, despite the README and architecture claiming "Proxy routes to upstream services".

Detailed Investigation Findings (release/1.7.31)

Current State:

  • Proxy routes exist in server/routes/sonarr.js, radarr.js, sabnzbd.js, emby.js, etc.
  • They forward only a small number of endpoints (e.g., queue, history, specific actions).
  • Many useful upstream endpoints (advanced configuration, full metadata, custom actions, etc.) are not proxied.

Impact:

  • Users expecting a transparent reverse proxy or full API passthrough are disappointed.
  • Forces users to maintain separate direct connections to Sonarr/Radarr/etc. for advanced use cases.
  • Contradicts the "simple all-in-one dashboard" positioning.

Proposed Solution / Fix Plan:

  1. Clearly document the exact list of proxied endpoints in README and /api/swagger.
  2. Either:
    • Expand the proxies to cover the most commonly requested endpoints, or
    • Add a generic catch-all proxy (with security considerations) for advanced users.
  3. Add a note in the architecture docs that full upstream API passthrough is out of scope.

Cross-Dependencies:

  • None direct, but improved proxying would benefit users managing season packs (#61) and webhooks by allowing easier configuration from the dashboard.

Suggested Labels:
Kind/Bug, Priority: Low, Area/Proxy, Documentation

Affected Versions: All versions.

**Description:** The proxy routes (`/api/sonarr/*`, `/api/radarr/*`, `/api/sabnzbd/*`, `/api/emby/*`, etc.) only implement a limited subset of the upstream service APIs, despite the README and architecture claiming "Proxy routes to upstream services". ### Detailed Investigation Findings (release/1.7.31) **Current State:** - Proxy routes exist in `server/routes/sonarr.js`, `radarr.js`, `sabnzbd.js`, `emby.js`, etc. - They forward only a small number of endpoints (e.g., queue, history, specific actions). - Many useful upstream endpoints (advanced configuration, full metadata, custom actions, etc.) are not proxied. **Impact:** - Users expecting a transparent reverse proxy or full API passthrough are disappointed. - Forces users to maintain separate direct connections to Sonarr/Radarr/etc. for advanced use cases. - Contradicts the "simple all-in-one dashboard" positioning. **Proposed Solution / Fix Plan:** 1. Clearly document the exact list of proxied endpoints in README and `/api/swagger`. 2. Either: - Expand the proxies to cover the most commonly requested endpoints, **or** - Add a generic catch-all proxy (with security considerations) for advanced users. 3. Add a note in the architecture docs that full upstream API passthrough is out of scope. **Cross-Dependencies:** - None direct, but improved proxying would benefit users managing season packs (#61) and webhooks by allowing easier configuration from the dashboard. **Suggested Labels:** Kind/Bug, Priority: Low, Area/Proxy, Documentation **Affected Versions:** All versions.
Gandalf added the Kind/BugKind/Documentation
Priority
Low
4
Area/Proxy labels 2026-05-28 11:40:30 +01:00
Gandalf commented 2026-05-28 18:54:06 +01:00
Author
Owner
Copy Link
Copy Source

The fix here will to be address the misleading documentation - there isn't an intent to provide full exposure of the upstreams.

The fix here will to be address the misleading documentation - there isn't an intent to provide full exposure of the upstreams.
Gandalf added the
Reviewed
Confirmed
1
 label 2026-05-28 18:54:27 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Docker
Docker image and container packaging
 Area/Download Clients
Download client integrations
 Area/Frontend
Client-side UI and build tooling
 Area/History
History and completed downloads views
 Area/Logging
Log streaming, file handling, and debug infrastructure
 Area/Matching
Matching and correlation logic
 Area/Proxy
Upstream service proxy routes
 Area/SSE
Server-Sent Events and real-time streaming
 Area/Webhooks
Webhook processing and reliability
 Compat/Breaking
Breaking change that won't be backward compatible
 Compat/Non-Breaking
Non-breaking compatibility change
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No Label Area/Proxy Kind/Bug Kind/Documentation
Priority
Low
4
Reviewed
Confirmed
1
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Gandalf
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Gandalf/sofarr#67
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?