Cloudron Forum

@james thank you so much! SOGoMailCustomFromEnabled worked prefectly!

Hello,

We are using a Cloudron group mailbox to allow multiple users to log in and process emails from a shared inbox.

Our main issue is that there appears to be no way to set or change a human-readable “Full Name” (display name) for a group mailbox. As a result, outgoing emails from the group mailbox always show the group name (e.g. group.name) as the sender. Since Cloudron enforces a restricted format for group names, this makes it impossible to define a proper display name such as a real team or company name.

Is there a supported way to define a display name for group mailboxes that is independent of the group identifier?

Additionally, we noticed the following behaviour with SOGo:
When a group is created (e.g. first.group.name) and the mailbox is opened in SOGo, this name is stored in the SOGo identity. If the group is later renamed in Cloudron (e.g. to first.group.name.v2), the identity name in SOGo is not updated accordingly.

Is this expected behaviour, and is there a recommended way to keep SOGo identities in sync with renamed Cloudron groups?

Thank you.

@james hi thanks for the article - I have checked it and I can not understand how to force-upgrade-with-custom-manifest. Do I need to fork the app from your repo and build a completely custom app? My goal is to enable proxyAuth to the existing app that has some data and users.

Hi @james thank you for the detailed response!

You can think of that process like an app update, that only updates the app to use the Cloudron proxyauth add-on and does nothing with the application itself.

Can you please point me to the documentation on how this can be done? I understand now that and app updates itself, isn't it?

If you have apps, that should not be publicly accessible, you could always only allow connections from specific IP-Addresses like e.g. a VPN.

Is it possible to block single app from public access within the same Cloudron instance? I do not want to overcomplicate the configuration and have nested servers...

@james thank you for the clarification and the link! Do I understand correctly, that proxyAuth add-on will respect the Access Control setting of the app and allow access only to the allowed users via their Cloudron authentication? The target app may want the extra auth then but that is fine.

Is there a way to add proxyAuth for the existing app? I do understand that documentation says it is impossible, but what if we have quite a big data already in the app that we want to protect and we are not able to just run a fresh install?

p.s. Just as a side note, what is the best way to isolate the particular app from the public interface? This will allow us to be able to hide any app without clear reinstall with proxyAuth. This public-interface disabling also would come handy if we wanted the app to only be allowed on the VPC interface (i.e. on our ZeroTier network, but not on the public).

@james hey yes, correct - I do not mind the apps to use their own user management but since we can not control/enforce proper rules over its secutiry we want to add proper cloudron auth on top of it. We are able to configure app proxy jsut fine, but we need a simple way to isolate these apps from the external IP so they will be accessible only via app proxy.

Hello @james ! Just normal cloudron apps like Mattermost or n8n that does not integrate with cloudron authentication and does not provide SSO

Hello,

We are using Cloudron (v9) to host several applications that do not support native Cloudron user authentication. To standardise access control, we have introduced a proxy app (running on the same Cloudron instance) that authenticates users and then forwards traffic to the target application. This is done by routing traffic internally using the 172.* Docker network IP and the app’s internal port, ensuring that users must authenticate before reaching the target app.

However, the proxy and the target app each have their own subdomain. The proxy correctly enforces Cloudron authentication, but the target app remains externally accessible via its own subdomain, bypassing the intended protection.

What would be the cleanest, most durable way to prevent external access to the target app’s subdomain, so that it is reachable only through the proxy? We are trying to avoid custom modifications or unsupported hacks that might break updates or interfere with Cloudron’s normal operation.

Thank you in advance for your guidance.