Cloudron Forum

Wow what a major rebrand, we need this indeed, as RC doesn't cut it.

@micmc said in Super Productivity: Offline I guess it has the option to sync via webdav. So it's like the ntfy frontend, it's all public but very limited in functionality.

That would indeed be useful.

Ah, thanks for the clarification @jdaviescoates

Hello @d1rk Thanks. Could you please now run the following command and share the output? lsof -i :53

I wrote a small script so I can monitor the HPB (turn) backend. Because if it fails, it breaks Nextcloud talk. Posted here in case anyone else wants to easily monitor his turns server. The cron job runs it once a minute. Each run generates REST credentials from the static auth secret, calls turnutils_uclient to allocate on the TURN server, and then sends a push event to Uptime Kuma containing either TURN allocate succeeded or the last error line from turnutils_uclient. So Kuma sees “up” whenever the allocate completes successfully and “down” when it fails.

@SolarSimon I've always just gone to /settings/apps/updates to see available updates for Nextcloud apps amd have never noticed anything about them in /settings/admin/overview nor anything about "Stable" apps (but there is a "Featured" label on some apps)

yes, maybe try to avoid pasting AI answers without proper vetting as such into the forum. And if so probably much better to only paste the relevant parts. There is little benefit in duplicating AI output here.

@joseph I just tried "App -> Repair -> Try task again" ... and it fixed both apps. ... Is now a good time to feel stupid? Asking for a friend...

Hi, @james! Yeah, I think you got it perfectly. Except I don't think the app-proxy would need to use OIDC instead of proxyAuth. Maybe It could be an option: You either use proxyAuth for authentication-only if your proxied app doesn't have auth capabilities, or you use OIDC and the proxied app would use cloudron as an OIDC provider. I understand there are a few technical hurdles to jump, but I'm thinking they might be feasible. The main one, as you suggested, would be to have the OIDC-related configurations in the manifest dynamically configurable. This feels like it would demand some work, but as I understand it, there's already something along these lines in apps like gitea, where the SSH port is declared in the manifest, but customizable via the web ui. IMO, this would make for a few more nice usecases for app-proxy, like testing apps, or even hosting them elsewhere (like a homelab in my case, or another machine), but accessing them through cloudron and benefiting from its user management. Also, I don't think it would "compete with" or "exploit" cloudron in any way, since these proxied apps would not benefit from cloudron's other great features like automatic updates, backups, external volumes, etc. All the management ease and just general peace of mind that cloudron brings us. Would be a nice use case, though, I think.

Absolutely. That's an excellent and thorough answer, @james . Many, many thanks. Possible text: This add-on is intended for applications that already support OpenID Connect-based (OIDC) authentication. Apply this add-on to use Cloudron as an OpenID provider with an application that supports OIDC-based authentication. Possible improvement for proxyauth: The proxyauth add-on allows you to put an authentication wall in front of an application. This is useful in situations where the application has no authentication mechanisms of its own, or where there are features that you cannot easily turn off (for the general public), and you want to restrict access using Cloudron's built-in user and group management tools. I think the idea being that, in both cases, a bit more "why" might help. Either way, thank you. All of my questions are answered (including "oh, hey, there was an app packaging topic!").