Cloudron Forum

This is a custom app based I am packaging on react-admin. I am currently just redirecting the user to {app}/logout on clicking logout. Any way to enable it for just the custom app?

This is fixed for the next release: https://git.cloudron.io/platform/box/-/commit/b5c75caea03a16aebcb761b9c60fbe71233c7936

We generally only package released versions of apps, as otherwise it becomes impossible to test all combinations. Hopefully they make a new release soon, which would then likely include the fix.

We will show the domain, for which the API call failed, in the error message for a start with next release. https://git.cloudron.io/platform/box/-/commit/f421fd771ff0e0550381d012414a6c35c8fd2afe

@RoloufGoudebin just to take a step back. Can you give us more background as to what happened to the server? Trying to understand why node symlinks have disappeared. If you can write to me at support@cloudron.io with more details, I can take a look.

@girish Thank you, girish for the update!

@stoccafisso DigitalOcean Spaces should work fine — it's a standard S3-compatible storage. The setup is basically the same as in the guide. Just use your DO endpoint and access keys.

@dylightful Which provider are you using to backup files? What version of Cloudron are you using?

Thanks @nebulon - It seems as overnight contributors have reported/added more information. I will certainly contribute if anything meaningful comes up from our side. In the meantime, the issue remains for now (previous version works though.)

the new package now disables the max body check for the nginx within the app. I couldn't quite reproduce the issue in my setup, not sure how you ended up with such big queries, but hopefully it fixes your case.

@girish What is the latest on OIDC logout support?

@girish Glad to serve. If the goal is an addon, then... I think the backup piece should be straight-forward? (I have some more info in the packaging thread about this.) Essentially, you want to make sure the SQLite DB is backed up, and then you backup the filesystem. I have questions about what happens if (say) a restore happens (e.g. what if the filesystem path changes?), but those things can be explored. There is an administrative API that (once you generate a secret/trusted admin API token) lets you do everything administratively via that API (bucket creation, etc.). As to a web interface, I would not recommend you create one for end-users. (I suspect this is not what you mean.) You have NextCloud, XBackBone, and other apps that can talk to an S3-compatible backend for file browsing. What people might need/want is a way to: Create/remove buckets (which, on the backend, you'd use your secret admin key) Create/remove keys and attach them to buckets Create/remove administrative keys (for superusers who want to script things against the backend) Bonus: the ability to designate a bucket as a static site, and then you do the DNS work on the backend to point either a subsubdomain at it (e.g. site.s3.example.com) or a whole new domain (e.g. someothersite.com -> site.s3.example.com) I suspect you could iterate towards this, if you wanted to. Release it with terminal-only management to start, and work towards an admin interface for common bucket creation/removal-type tasks. There are things that Garage does not do (e.g. lifecycle rules), so this is not a "full" S3 clone (the way Minio aspired to be). In this regard, SeaweedFS might offer more features (and a built-in admin UI)... so, it might be worth doing a spike to explore it as well. At a glance, it is similar, but it also is intended to scale (e.g. it does Raft consensus and Reed-Solomon EC if you want it) in a way that Garage does not. This might also be a reason to not use Seaweed. I can poke it with a stick if it would be valuable. Update, a few hours later: I would recommend sticking with Garage.