[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..

[Joly0]

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..

No worries, and thanks for taking a closer look. That approach sounds better to me too: built-in child apps mean everyone gets support without setting anything up, and showing only proxied apps in the header solves the clutter problem.

Much of this PR could carry over: the ID offset at 100, fetching and caching the OpenAPI spec, the icon handling, and the per-app nav setting. Though i think an approach that everyone can benefit from would need a central storage for people to contribute more easily, and not through manual github PRs, or what did you have in mind here? Once you've decided how you want the UI and the add flow to look, let me know and I'll try to rework it in that direction.

[austinwbest]

My initial thought is a blank header with an [+ Add app] button kind of thing, that opens a simple dialig with the starr information (the fields in the table basically) and then it becomes a header icon for that app. from there the current process kids in with the tabs and adding 3rd party apps.

For sure a lot of the logic you already had carries over so that will save some time

I'll think on a better way to get user edits from the app to github vs manually creating PRs.. maybe a way to pipe it through the notifiarr API which allows the bot to then automatically create GH stuff (this can come later)