@nebulon My thinking for write protection was actually that it could - literally - use filesystem permissions rather than introducing a database. Check if the file is writable before deleting/writing, and fail if it isn't writable (or offer to override, which will have to chmod +w it)
+1 for IPv6. Had a situation come up recently where IPv6 would have (apparently) resolved it when it came to email block lists. Of course the easier workaround for me is to use a mail relay instead of the built-in SMTP server, but IPv6 was a second alternative presented by OVH who is responsible for the IP range mine was included in.
@girish Indeed, the pad had ‘freely’ permission; but that should mean freely editable only to people knowing the URL. By clicking a link in the pad, the pad’s URL was made available to the owner of the linked website.
This was required as part of another feature - making it possible to restore Cloudron without updating DNS (https://git.cloudron.io/cloudron/box/-/issues/737). Currently, it is not at a domain level but at a global level (can always add it later).
I think in theory we could isolate app containers to access only a specific db by restricting based on IP (which MySQL supports). MySQL already has an IP based rate limit for logins, this is why we haven't implemented it. Meaning, an app trying to guess another app's db credentials won't get very far.
@d19dotca yes, definitely, if the status page has support for incoming webhooks.
for me, the use case is have up/down events of apps in our rocket.chat. we just have to pipe the notification stuff to a webhook, it's fairly straightforward to implement this feature.
For my use case I only need up and down events. But are you planning on adding a web hook for all notifications?
