Cloudron Forum

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

@james I restored to a previous image, downloaded the backup of my apps. Completely wiped the server, deleted my linode and its disk image backups. then switched host providers. Maybe this information will help if some one else runs into the same problem. This server was a cloud image install, through Linode. I never did any manual configurations, always followed official docs. Never had a problem. Was solid for 3 years. Server updated on its own from the last 8x version to 9.0.11.

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!").

Hello @james, Thank you. My bad I completely overlooked the documentation Alright I'll give it a try

Hello @scooke Since the app element is just a front-end for matrix, the user-management of the matrix home server is the one you are actually looking at. I installed element at https://elm.cloudron.dev and 2x matrix home servers. 1x allow all cloudron users at https://moidc.cloudron.dev 1x Leave user management to the app at https://mself.cloudron.dev. OIDC - moidc.cloudron.dev When I configure element to use moidc.cloudron.dev as the home server, I correctly get the Cloudron user management when trying to register or log in: [image: 1764072459374-332f90b8-b432-4237-851c-347183afb0f8-image.png] Self Managed - mself.cloudron.dev When I configure element to use mself.cloudron.dev as the home server, I correctly get the user management of matrix itself when trying to register or log in: [image: 1764072395122-48ceb83e-f8b6-4be9-bb25-cb02db6f10d8-image.png]

Hello @Felipe.rubilar Have you tried clearing the application cache itself? Open the web terminal of your freescout app and run the following command: sudo -E -u www-data php artisan freescout:clear-cache

@swheeler78 https://docs.cloudron.io/backups/#restore-cloudron has the workflow .

Guys, tyvm for your feedback. As a workaround I simply disallowed dav on a group level. Nevertheless I'll feature request this during Christmas time. ^^

@girish said in Attempted to restore Cloudron 9.0.12, receiving error when loading backup configuration and hitting Restore button: @d19dotca I tried to reproduce this but I couldn't figure where to set this IP allowlist in iDrive e2. Maybe it's only for paying customers since I am on the trial plan ? Hi Girish. This link can help, assuming it isn’t gated to paying customers (I’m not sure if it is or not), but hopefully this provides some instructions for setting up an allowlist. https://www.idrive.com/s3-storage-e2/faq-buckets#ip-allowlisting I suspect you’re right though, that it is sending back a non-XML response to provide a response message that it’s forbidden from accessing it. I understand this use-case may be rare, but I think if there’s a way to improve that error handling, it may help others too because at first glance it’s really not clear where the issue could be coming from.

Hello @OneTools-Project By default Cloudron will always configure the app. You will have to disable the configuration the the Cloudron Dashboard of the Listmonk app: [image: 1764025216798-d75bb7a5-3cab-43f3-86bb-228fdaff2ccb-image-resized.png] after selecting this, the SMTP setting will no longer be changed.