Cloudron Forum

@girish said in Accessing email mailbox owned by a group:

Let's say a username has 3 mailboxes - admin@, support@ and username@ . Which mailbox is seen when logged in? You might say username@ but what if username@ is not in that list?

@girish I think we keep misunderstanding each other here. I know how it used to be back in the day and I also know that for ages now Cloudron has been using the full email address as username to log into emails exactly because of the confusion you've just pointed at with the above example. So I'm with you here.

What I'm pointing out is that if using the email prefix as username to login (and NOT the Cloudron username) then we get around the confusion in your example. So if a user is the owner of three mailboxes - admin@, support@ and username@, then to log in each other them the username would simply be "admin", "support" and "username" respectively, and the password is the user password. I'm not taking about showing multiple mailboxes at once or anything like that. With a single domain this works, there is no confusion and yet we don't need to write the full email address every time but only the prefix which is easy. And this is what seems to be happening in Roundcube right now.

Now this gets confusing with multiple domains becasue a single user can be the owner of say admin@domain1.coop and admin@domain2.coop. But for this "I humbly think" the default behaviour I described in my previous message intuitively solves this issue, that is:

• if a user enters only the prefix then the @domain defaults to the domain the webmail app is installed on. So say if Snappymail is installed at webmail.domain1.coop and I enter "admin" as a username to login, then it default to the mailbox admin@domain1.coop.
• if a user enters the full email address as the username to login then he/she/they can access that mailbox no matter what the domain of webmail app is.

Here is what I wrote in my previous message:

I think it would make most sense and be the least confusing if the username to login is the prefix of the email address, and that it default to the domain of the email app rather than the global email domain. I think that way would be a very neat approach, yet still giving the flexibility to login on any email app installed on the Cloudron using the full email address for niche use cases.

@girish I see, thanks.

Can I just ask a couple of clarifications:

1. When you say username, do you mean prefix of the email address (the part before the @ in the email address) or the Cloudron username?
2. when you say the email domain, do you mean the global email domain (MX domain), or the domain on which the email app installed?

I think the current behaviour actually makes sense and is quite convenient to login rather than having to enter the full email address every time. I think it would make most sense and be the least confusing if the username to login is the prefix of the email address, and that it default to the domain of the email app rather than the global email domain. I think that way would be a very neat approach, yet still giving the flexibility to login on any email app installed on the Cloudron using the full email address for niche use cases.

What @jdaviescoates describes is that it seems email apps accept the prefix of an email address (the part before the @) instead of the full email address as the username

It is to not that using just this approach would make a lot of sense if a given of an email app was restricted to emails on a single domain (as @girish mentioned, what NEVER makes sense is to use the Cloudron username as a single user can have several email addresses, even within one domain).

So one question is: say if there are two domains on a Cloudron, domain1.coop and domain2.coop, with several mailboxes on both domains, then is it the expected / default behaviour that with an email app installed at: webmail.domain1.coop, one should be able to access any mailboxes on Cloudron (i.e. on both domain1.coop and domain2.coop), or should one be able to access mailboxes only on domain1.coop?

It's with Roundcube, and it's up-to-date

@girish Hi Girish, I know what you're explaining is the expected behaviour, I've been a long time Cloudron user. What I'm pointing out to you is that it DOES WORK to just enter the group name as the username for group owned mailboxes on my Cloudron (8.1)....which I thought was weird which is why I'm letting you know (and was asking, is this the expected behaviour for group mailboxes, and if so, how would it work in the case of multi domains).

Unrelated to the original post, but today I have noticed that for mailboxes owned by groups, only typing the group name as username to login was working (instead of groupname@domain). Is that an intended behaviour?? I like it personally, but I wonder how it'd work for instance with multiple domains and the case where there are two mailboxes: mygroup@domain1 and mygroup@domain2?

I'm on Cloudron 8.1

@nebulon Yep the umbrella app is MiroTalk WEB / WebRTC. Seems pretty useful to deploy this within an organisation but I also understand why that's not the priority (definitely better to have the actual functional apps before the umbrella one).

@nebulon is the plan to then have it all under the MiroTalk WebRTC integration? It looks fantastic!!

• Summary: a meeting schedule app with modern / mobile friendly ui, calendar integration and super easy to fill in polls (when2meet style).

• Main Page: https://schej.it/
• Git: https://github.com/schej-it/schej.it
• Licence: GPL-3.0
• Docker: Not yet but hopefully coming soon: https://github.com/schej-it/schej.it/issues/118
• Demo: https://schej.it/

• Notes: it's got a very very slick interface / modern UI and utilise the same way to fill in availabilities as wehn2meet which I think has the best and easiest workflow. I recently tried to do a poll with Rallly with many dates and slots and it was a real nightmare to fill in. Additionally it has a calendar integration for auto-fill of availabilities, which is cool, though I personally don't care much about that feature yet (but I will once it supports Nextcloud). I know we already have Rallly and Cal on Cloudron but this one is MUCH better than the former, and serve a different purpose than the latter....so I reckon it's got its space in our much loved Cloudron universe

• Alternative to: When2Meet, Rallly.co Doodle and the like

Is there any change log published anywhere for new version of MiroTalk? It would be useful.

@MiroTalk do you publish any?

@firmansi And I guess that would get solved if you ran your instance on a more local server...one more reason for Grist on Cloudron

@jdaviescoates said in How to setup Hetzner Storage Box using SSHFS:

@avatar1024: you've mentioned previously that you've had issues restoring from SSHFS - is that still the case?

I've had no more issue restoring using sshfs. I had issues (getting the same error message as you) when using specific ssh key pairs. rsa keys have been more reliable than Ed25519 keys, and do not protect your key with a password. Then it should work like a charm. See my post here: https://forum.cloudron.io/post/86213

Thank you for this, I've started looking into how to pull all of the logs and will submit as soon as possible.
One thing I can say is that it definitely seems to happen a lot more when hotspotting from my phone on mobile network but also happens with stable home WiFi. Trying other tools like zoom, teams or the public jitsi I have no issues whatsoever.
Also I can only make it work with Firefox, with chromium (ungoogled) I get no camera and other problems (whereas all other platforms perform better on Chromium).
So it'd say for me the tool in it's current implementation is not yet ready for production / environment. Even the public jitsi is way more stable.

I keep hitting this with MiroTalk SFU and so I have to enter the room many times during a meeting. It's me who set-up the room but strangly other participants in the meeting did not have the problem and could carry on with the meeting while I was dropping out.

Hello, it looks like Noco supports authentication with OIDC (Auth0). Does that mean it's now possible to have a package that uses Cloudron users?

Hello, I wonder, is anyone is working on this? Seems like grist is ahead of the others regarding what it offers in the self hosted version.

@girish said in What's coming in 9.0 (was 8.0):

@avatar1024 we have to revisit this when we plan for 9.0 . currently, we focus on 8.0 - https://forum.cloudron.io/topic/11531/what-s-coming-in-8-0

Sure, I just wondered as it wasn't listed in the list at the top of this thread.

Sorry I'm sure this has been discussed but has the plan been dropped to have a unified dashboard across several instances?

@MiroTalk said in Use Cloudron Logins for host protected settings:

Not a behaviour intended! I'm considering a refinement where guests are only allowed to join specified rooms that have already been created by authenticated users. This approach might offer better control and security. Will be released in the next version.

I thought that might be the case. Though as I mentioned the behaviour is achieved though by setting "protected: true" in the config.js combined with OICD. It just feels like if OICD is enabled then it shouldn't be possible for guests to create rooms so the setting shouldn't be necessary.

Thanks for this. Just to make it clear to people, in order to obtain the behaviour in 2, you still need to modify the config.js file and enable authentication (protected: true). Otherwise, while guest cannot enter the app base domain without a login, they can still create rooms freely by creating a url: mirotalkappprefix.mydomain.com/join/roomname

@MiroTalk is that behaviour intended?

@nebulon perhaps the "protected: true" should be enable by default in the package with OICD as I imagine this is the behaviour most users expect if they want authentication?