[Joly0]

I have been running this feature on my own instance since March and only now got around to filing it upstream. For this PR it was rebased onto current develop and partly reworked; the reworked version is what is tested below.

Problem

Only the six built-in starr apps can be proxied. Forks and newer *arr-style apps (Chaptarr and similar) speak the same API but cannot be added.

Change

• Settings > Custom Apps: add an app with a name, label, API version, optional OpenAPI URL (for endpoint discovery in the access dialog) and optional icon. It then works like a built-in app: instances, 3rd party apps, templates folder, nav entry with a show/hide setting.
• Custom app IDs are the row id + 100 (StarrApps::CUSTOM_ID_OFFSET) so they never collide with built-in IDs; getAllAppsList(), getStarrInterfaceIdFromName() and friends include them.
• Connection test for custom apps uses /api/{version}/system/status, since config/host is not guaranteed outside the core apps.
• Migration 009_custom_apps adds the custom_apps table.
• Nav visibility changes on the settings page apply without a reload (data-nav-setting), and the access form shows an error toast when it fails to load.

Hardening in this feature:

• All custom app queries use SQLite3 bound parameters.
• Icons: PNG, JPEG or WebP only, detected from the image content (not the filename), max 256 KB, stored as <name>.<detected ext>. No SVG.
• Name: ^[a-z][a-z0-9]{1,31}$, cannot be a built-in app or a page name (?app= is routed before ?page=).
• OpenAPI URL must be http(s); checked on save and again before it is fetched.
• Names, labels, icon paths and the endpoint names from OpenAPI files are escaped in the nav, settings, starr page and access dialog.

16 files, about 600 lines. Happy to split or change anything if you would like it shaped differently.

Testing

Built from this branch with an existing database (migration 007 to 009 ran).

Check	Result
Name Bad Name / settings / radarr	rejected with a message
API version 3, OpenAPI URL file:///etc/passwd	rejected
Label Te'st"); DROP TABLE settings;--	stored literally, settings intact
SVG renamed to .png, PHP renamed to .png	rejected
Real PNG	stored, served as image/png
Delete app	app, nav setting and icon removed; refused while instances exist
Custom app page, settings list, nav	render, no PHP errors

[austinwbest]

Thanks for taking the time to build it out. The current workflow:

You can already have local templates and assign those and build those out. The idea is when adding a new app that would be used and once the endpoints are sorted out for required permissions, PR the template and then anyone can use it as it would be part of the app.

Edit: Feel free to join the discord server, there is a #starrproxy channel there and we can discuss things a little faster as well. Just ping me if you do.

[austinwbest]

Sorry, i responded to this before looking further into what you where doing. My brain registered as something other than adding more top level app support.

Let me think on this as ideally it would be better to do this in a way that benefits everyone and every user doesnt have to create custom app support.

Might require a little UI changing but possibly a group of the "parent" starr apps (current ones) and then a group of "children" apps. they would be added internally like the parent apps with their own ids and what not and can start at 100 like you did. to avoid cluttering the header we would need to think on a UI change to handle it. maybe a different flow for adding external apps that has a different screen where you pick the starr (parent or child) and link it up that way. then the header just shows what you have proxied..