CCAI : Cloudron Custom App Installer

[timconsidine]

Note : creating a dedicated App Wishlist for the Cloudron Custom App Installer ("CCAI"), to avoid further "hijacking" of @Kubernetes thread in App Packaging forum category.

This app makes it easy for a Cloudron user to install a custom-packaged app without having to clone the repo locally, install docker locally, build the docker image and push to a docker repository, and install Cloudron CLI to make the installation.

This appeals to :

• cloudron users wanting to keep their local device clean of dev utilities
• cloudron users who are not technically comfortable with the manual clone/build/install process

It is not a 1-click install, given the need for user to login to their Cloudron instance, and enter app location, but it's as close as we're going to get.

Latest version v4.1.1 :

• adopts suggestion from @robi to allow list of available custom apps to grow w/o intervention (popup dialogue for user to add a custom app to a list for themselves and others to install)
• tightens the UI to allow more custom apps in the list
• adds Grid or List display mode for known custom apps
• improves page responsive UI for different window widths

git repo : https://git.cloudron.io/timconsidine/cloudron-customapp-installer

home page : https://ccai.appx.uk
This page is left running as a service for Cloudron users wanting to install custom apps in advance of this app (or another Cloudron-supported version) making it into the App Store.

concept video : https://ccai-demo.appx.uk (but video needs an update for latest version UI and usage flow)

NB : the ability for an app packager to add their own custom app to the list without the site admin's involvement reinforces the NEED FOR CAUTION ON INSTALLING CUSTOM APPS.

• Check the app's reputation in the Cloudron forum
• Check the app packager reputation in the Cloudron forum.

TODO :

• add optional keep me logged in for 15 minutes to allow the user to install multiple custom apps without repeatedly logging in to their Cloudron instance.
• update the concept video for latest UI and usage flow

DISCLAIMER :

• this app inherently carries some risks that a poorly-packaged app mucks up a Cloudron instance. However Cloudron's app-isolation principles mitigate this to a large degree.
• nevertheless, only use this app if you understand and accept the risks
• for these reasons, it is understandable that Cloudron may or may not want this kind of app in the AppStore
• [@]staff or any developer are welcome to fork or re-write this app to improve it and address these issues

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

[timconsidine]

@ruihildt it’s not about not wanting to. It’s about how far to go and I’ve opened up that discussion.

I have already put some antibot measures in some places. Adding some additional rate-limiting this evening.

I am very open to discussing how much further to go.
If you have any specific suggestions, I will gladly implement them (working on a 1-time authorisation. But frankly 2FA handles that much better anyway).

I agree it’s not ideal, but I don’t feel it’s that risky.
It uses exactly the same security that Cloudron uses.
So if it is insecure, then by definition Cloudron is insecure.
As always, all Cloudron users should :

• have secure long passwords
• use 2FA
• ideally follow the recommendation to create a dedicated special purpose user and change its password after each use.

No login creds are stored - code is open for inspection to confirm that.

My clear preference is for this app to be in the AppStore so I can take down my site.
If the Cloudron community prefer this to be taken down or locked down further, I will happily do so.

The app and the site are just a response to the 100’s of requests for an easier way to add apps.

[timconsidine]

New version : v4.3.2 (git.cloudron.io updated)
Added optional Cloudflare Turnstile support.
Default : not enabled
Edit /app/data/.env to enable and add your config keys

The 'hosted-as-a-service` ccai.appx.uk is now running with Turnstile for anti-bot protection.
If you install this to your own Cloudron, you can choose to run without Turnstile or to enable it.

Why Cloudflare Turnstile ?

• easiest / best non-google captcha type anti-bot
• free account with generous free-tier usage
• minimal code dependencies to simplify app building

Beyond this, it would need a user registration or failed login rate limiter.

[LoudLemur]

@timconsidine said in CCAI : Cloudron Custom App Installer:

Cloudflare Turnstile

We had a thread here about CAPTCHA alternatives quite a while ago. One issue with Cloudflare is that it is unfortunately rapidly becoming a single choke-point for the whole internet. I ran a quick AI search for Free Software alternatives to proprietary Turnstile. This is what was suggested:

Several open source alternatives to Cloudflare Turnstile exist, focusing on privacy-friendly bot protection, spam prevention, and user verification without relying on proprietary services. These often use proof-of-work (PoW) mechanisms to verify legitimacy invisibly or with minimal user friction, similar to Turnstile's approach. They are typically self-hostable, allowing full control and avoiding central choke points. Below is a list of notable options, including key features and implementation details.

ALTCHA

Description: A privacy-first CAPTCHA alternative that uses PoW to protect websites, APIs, and forms from spam and bots without tracking users. It's designed for seamless integration and escalates to code challenges only for high-risk cases.
Key Features: Frictionless verification, WCAG 2.2 AA accessibility compliance, support for 50+ languages, no cookies or fingerprinting, and optional Sentinel for advanced threat detection (e.g., rate limiting, ML-based analysis).
How it Works: The widget runs a PoW challenge in the background; if solved, it generates a token for server validation. Self-hostable via Docker, AWS, Azure, or Kubernetes.
Licensing and Cost: MIT license for the core (fully open source and free); Sentinel is commercial for enterprise needs.
Advantages over Turnstile: Smaller bundle size (30 kB vs. 85+ kB), faster load times (0 ms when bundled), and stricter privacy compliance (GDPR, HIPAA, etc.) with no data leakage.

mCaptcha

Description: A no-nonsense, PoW-based CAPTCHA system emphasizing user experience and privacy, acting as a drop-in replacement for traditional CAPTCHAs like reCAPTCHA.
Key Features: Seamless UX without image puzzles, robust against NAT users (no IP reliance), API-compatible with reCAPTCHA/hCaptcha, and focused on making bot attacks computationally expensive.
How it Works: Clients solve adjustable PoW challenges; the backend verifies them. It's fully automated and doesn't contribute to third-party ML training.
Licensing and Cost: AGPL for the core, with client libraries under permissive free software licenses; entirely free and open source.
Advantages over Turnstile: Fully self-hosted with no external dependencies, stronger emphasis on not profiling users, and libre software ethos.

Cap

Description: A lightweight, modern PoW CAPTCHA using SHA-256 hashes, designed for speed and simplicity as a direct alternative to Turnstile.
Key Features: Invisible and floating modes, standalone REST API for any language/framework, customizable difficulty, and WASM solvers for web/Node.js.
How it Works: The widget generates and solves challenges via Web Workers; the server validates them. Supports checkpoints for progressive verification.
Licensing and Cost: Apache 2.0 license; fully open source and free.
Advantages over Turnstile: Tiny size (12 kB widget), no tracking/fingerprinting, lower error rates, and higher customizability (full backend/frontend tweaks).

Anubis

Description: A Web AI Firewall utility that weighs connections with PoW challenges to block scrapers, bots, and DDoS attacks before they reach your site.
Key Features: Heuristic-based bot detection, customizable rules/policies, non-JS challenge support, and integration as a reverse proxy.
How it Works: Responds to requests with a JS (or non-JS) PoW program; only solved challenges grant access. Tunable difficulty makes scraping unprofitable.
Licensing and Cost: Open source (repository on GitHub); free to use and self-host.
Advantages over Turnstile: Explicitly targets AI scrapers and bots, supports broader heuristics beyond PoW, and has been used to mitigate real DDoS incidents.

mosparo

Description: A rule-based spam protection tool for online forms, functioning like an email spam filter rather than a traditional CAPTCHA.
Key Features: Checks form data against custom rules, honeypot fields for bot detection, accessibility compliance, and multi-language support.
How it Works: Integrates into forms to validate submissions server-side based on patterns/rules; blocks spam without user-visible challenges.
Licensing and Cost: Open source under a permissive license; free and self-hostable via Docker.
Advantages over Turnstile: Less intrusive (no challenges for legitimate users), focuses on content analysis over behavior, and fully accessible for screen readers/keyboards.

Procaptcha

Description: A privacy-focused verification tool redefining CAPTCHA with unique security approaches, often listed as an open source option for bot protection.
Key Features: Emphasizes privacy and security without conventional puzzles; details are limited but include freemium elements for scaling.
How it Works: Uses alternative verification methods (potentially PoW or similar); self-hostable with open components.
Licensing and Cost: Open source with freemium model (free tier available).
Advantages over Turnstile: Open source core allows modifications, though less detailed comparisons are available.

[nostrdev]

Agreed that we should not use cloudflare, not just from the single-point-of-failure perspective, but also to protect user privacy

[timconsidine]

I’m not a fan of Cloudflare - just put it in as fastest way to address a possible vulnerability.
But proof of work is often a pain for users.
I feel there are only 2 good solutions :
Cloudron re-write as an official utility (resolves authentication much more neatly)
CCAI adds user registration
I’m thinking what direction to take it in if not adopted/rewritten