CCAI : Cloudron Custom App Installer

[timconsidine]

Updated to v4.2.0 :

• user session persists for 15 minutes to allow multiple installs, then automatically cleared (addresses user walking away), or logs out if user presses logout button
• N.B. this is a change from initial approach of auto-logout after an app installation
• fixed support for multiple concurrent users

Repo updated

TODO :

• update video walkthrough for new app flow

[luckow]

Yesterday, I tried out CCAI. Nice approach. Simple, flawless, straightforward. After installing CCAI on my own Cloudron instance, I noticed a discrepancy between the "App Catalog" on your instance and mine. What is your roadmap for synchronizing the catalog across all installed CCAI apps?

[timconsidine]

@luckow if CCAI is installed in another location, the app catalog will currently diverge as the data is drawn from /app/data/apps-config.json.

TBH I did not think about a “central” catalogue but that’s a nice idea as an option.
Let me think about how to implement.
Maybe a “Sync Catalogue” button.
But one-way or two-way ?
Maybe one way to start.

[robi]

@timconsidine how about a wget that grabs the master apps-config.json during any install/visit?

[timconsidine]

@robi good idea
Away for a week
Will do when I am back

[nostrdev]

If this app were available in the cloudron app store, it would make cloudron significantly, even exponentially more useful - as it would open up an entire universe of apps that the main cloudron team cannot / would not support.

The difference between iOs "walled garden" and the Android "sideload option". Android is far more ubiquitous as a result.

Obviously it comes with risks, and they should be well highlighted, however for those who understand and accept those risks a tool like this is just fantastic for enabling a plethora of new use cases on cloudron

If this app were deployed, we would also be incentivised to package up more apps, because the audience would be much much bigger

please do it! I would say it's even higher priorirty than our own app submissions (as we could easily use this tool to deploy them in the meanwhile)

[timconsidine]

@luckow @robi and anyone else interested

New version 4.3.0 pushed to git.cloudron.io/timconsidine/cloudron-customapp-installer :

• added button to import a catalogue to an instance running on your own URL : the default is to install from my hosted instance at https://ccai.appx.uk, but this value can be overridden so you can import from any instance of the app running under another name/URL
• added trash icon to Grid and List views allowing an app to be removed from the running app's catalogue, if it is no longer needed or import does not work quite as expected
• added auto-backup of catalogue prior to a deletion (so admin user has access to previous versions if someone goes wild on deletions)

About deploying this :

• if you have already installed this app to your own Cloudron instance, make sure you backup the contents of your local apps-config.json because installing this version will wipe your instance.

About import :

• imports whatever is in ccai.appx.uk (or specified URL) catalogue, so I can't offer any assurances on this, as I can't watch the catalogue constantly, but will endeavour to keep an eye on it
• therefore continue to exercise caution on installing any apps listed in the catalogue
• the import process a "dedupe" function built in, so anything imported should not overwrite an existing entry that you may have added to your own catalogue

I'm in a quandary about adding authentication to the app.
Generally I should, but it gets in the way of keeping ccai.appx.uk as an open hosted resource.
I will think about an elegant way to handle this.

[nostrdev]

Authentication would be good. Probably not a good idea to normalise the act of entering admin creds onto another cloudron instance, it's an invitation for bad actors

[robi]

@nostrdev That's what API keys are for, no?

[timconsidine]

@nostrdev totally agree

The issue is I'm unsure about the approach strategically in terms of keeping the "hosted as a service" URL open and easy to make use of.

I can easily add http basic auth or use Cloudron proxyauth but communicating those creds has a raft of issues.

I can add proper user registration, but it kinda goes against the original principles of it being an anonymous utility. I don't really want to be maintaining user records or responsible for them, and it's a pain for users to create yet another username and password for this (because obviously they should not be using Cloudron login details).

Maybe I can add some kind of automated short duration one time code delivered by SMS or email. Doesn't help much but maybe one blocker to scripts without a person behind it.

Ideally auth would be handled best by the app being within the AppStore, but that's not in my hands.

Any clever ideas gratefully received.
Otherwise I might have to bite the bullet and implement a user registration system.

[timconsidine]

I have thought deeply about adding auth or anti-bot measures.

My current conclusion is that anything I add (captcha, Cloudflare Turnstile, user registration in-app or via Keycloak) is going to :

• reduce the utility of this as a hosted app for easy use by those who don't want to install it themselves
• impact anyone who chooses to deploy the app to their own Cloudron with extra dependencies.

So at this point "the juice is not worth the squeeze".
I have however :

• added some rate-limiting for catalogue entry deletions
• added static text to recommend using a dedicated cloudron user for use with this app

I will think about creating a locked-down version with auth for those who want to deploy it to their own Cloudron, while leaving the hosted version w/o auth (basically my risk on the catalogue, because the actual app installation process is secure already).

Hopefully once Cloudron 9 is out and settled down, the version with proper auth can make it suitable for App Store inclusion, and I will retire the open hosted-as-a- service version.

I will review this later, but leaving it here for now pending further ideas.

[ruihildt]

Serving this online seems incredibly risky and inviting users to enter their credentials on a random website seems setting a very wrong example.

If you don't want to deal with antibot measures etc, you could package it as a tauri app for example. But now you are a packaged app developer and distributor.