What's coming in 6.0 (take 2)
-
@girish said in What's coming in 6.0 (take 2):
When you have time, please split them out and I can start approving them as unstable already.
OK, will do. I will have to pick your brain a little about how to handle authentication for these apps. In river, they're behind a custom auth proxy, as they don't handle auth by themselves.
-
@mehdi said in What's coming in 6.0 (take 2):
OK, will do. I will have to pick your brain a little about how to handle authentication for these apps.
Would it make sense to bring that into box code somehow? Maybe we add some flag in the manifest to turn on this "authentication wall".
@nebulon Is it possible to have a login screen like the surfer app but served from box code? I guess session management possibly won't work since app has no clue about this? Maybe logout won't work as well since there is no logout button in the app.
-
@girish said in What's coming in 6.0 (take 2):
Would it make sense to bring that into box code somehow? Maybe we add some flag in the manifest to turn on this "authentication wall".
It would be possible yeah. An other possibility would be to have a standard way to do it in the "base image", to make it easy to implement in the apps that need it. I would probably go with the "base image" path, because it would be easier to configure on an app level IMO.
-
@mehdi Good idea. Maybe then for the moment we can copy/paste apache configs in every app (like https://git.cloudron.io/cloudron/simple-torrent-app/-/blob/master/apache/cloud-torrent.conf ) for now and once we have a something common, I can try to put it in the next base image.
-
So the idea is to put some kind of "framework" into the base image, which can be used by apps? Wouldn't that anyways still not mean that an app needs to be patched for at least the logout action? Also would we do this as a php set of features? I do like to not pull this into the platform code as such, as that does not increase dependency on that.
Alternately, we could certainly add a login screen served up with some kind of session. The question then, as already mentioned, is how to logout. We could provide the app with a logout link, still that needs patching the app to some extent.
-
@nebulon IMO the login part is much more important than the logout part. We can even do completely without the logout at all in the interface, with just a
/logoutURL that one would have to enter manually (if ever).As to the precise tech to use, I already have a working version in Node.JS in river that I could isolate. If you guys prefer to re-do it in PHP instead or something else, it's your choice.
-
Right, I was only bringing up php since that might be more commonly already be used within such apps, I would prefer a nodejs solution though. Maybe we can collect some arguments for and against adding to the base image or into the platform.
If we add it to the platform, we could have it more easily streamlined with the Cloudron look and feel, however within the base image the app could style it more towards its own look and feel. Putting it in the platform on the other hand would allow support translation now once it fully landed. Also say we use a nodejs based version, then we have to keep running an additional process with possibly another proxy even?
-
Just pointing out that this might be better served by using something like a proper gateway and load balancing solution in front of the apps like Kong rather than NGINx on the box. An add-on for a basic auth screen could just be a config tweak to the box ingress which hits an auth wall - added advantage would be much more flexible routing to apps (sub-path, etc.) and flexible options like having multiple DNS names resolving to the straight A record for things like apps that can serve multiple domain names off one instance.
-
@jimcavoli
You mean to use Kong or Traefik (this are exeple) as incoming proxy for every container ?If yes, we need to consider how reliable is Nginx and the feature that can be easily added (Proxy_Cache, brotli, WAF, ...)
-
@moocloud_matt yeah, there's currently a
boxlevel NGINx proxy - my idea is to replace that with a very hand-wavy something else which may be capable of shimming authentication for those things that just don't have it inbuilt (Kong) or if we go a different route on that sort of thing, we could use Traefik or similar at that layer. I think the use cases are intriguing enough to at least try the Kong route and fall back to something like Traefik if need be -
@jimcavoli
for adding .htpasswd support ? or what kind of auth are you talking about? -
@moocloud_matt Kong is a pretty expansive topic on its own, but the idea would be with it in charge of ingress/routing, you could have a simple add-on config that would take care of enabling a plugin like https://docs.konghq.com/hub/kong-inc/ldap-auth/ on the route to a particular app, so you could have HTTP basic auth, but completely backed by the full Cloudron user store for any app that doesn't have its own scheme, providing clean headers that could be easily handled by that app's eb server or whatever
-
Kong is indeed a separate complex topic. I think for the moment, if we had some template that people can quickly copy over to the app to get auth screen/login, it will help already. @nebulon do we have such a template already ? (like the one we use for our internal apps).
-
@jimcavoli
i think that's possible with nginx too, the ldap backend for auth.
Custom Template for nginx config, will be the best i think, especially for performance optimization.But this Kong proxy is interesting i will ask to my team, if they have use it.
Matteo. R.
Founder and Tech-Support Manager.
MooCloud MSP
Swiss Managed Service Provider -
@girish said in What's coming in 6.0 (take 2):
Kong is indeed a separate complex topic. I think for the moment, if we had some template that people can quickly copy over to the app to get auth screen/login, it will help already. @nebulon do we have such a template already ? (like the one we use for our internal apps).
Yes in various shapes, but all nodejs based. This would be trivial to add, however if many of those apps are just apache+php does it make sense to add supervisor+nodejs+someproxy to those apps just for a login screen?
-
@girish quick question in the mailbox sharing feature. If you make it so that a single inbox can have multiple owners (great feature btw), do you think it would then be possible to have the option to set a group as the owner so the mailbox ownership gets dynamically updated with changes in group membership? Thanks
-
@avatar1024 Yes, that's the idea. The ownership will be dynamic.
That said, the initial outlook for the feature is not looking so good. There are two issues that need to be sorted out (suggestions/ideas welcome):
-
Apps like SOGo show the "display name" of the user in the main UI. With a shared mailbox, it's not clear where this name should come from. With a single user, we give SOGo, the user's name. With multiple users, it's not clear what this should be.
-
The authentication (from a user's point of view) is a bit confusing. Or maybe it's not, I would welcome some feedback here. You have to authenticate with the user's username/password but use the shared mailbox as the mailbox name. In some ways, this is the case already, when you use a different mailbox name with a different username.
-
-
@girish thanks for the reply.
Perhaps there are a few things I do not understand about the technical implementation of such a feature but I will still try to give my opinion. As you describe in the first post on this thread the idea is, rather that a "shared mailbox" as such, to have a single mailbox with multiple owners, so:
-
for point 1) I suppose you mean that the name of the "owner" is fed to the app when the owner is assigned to the mailbox rather than when the user logs in? If so, would it possible to feed the name of the user that logs in into that (which will be recognised through its unique pair of credential: mailbox name + its unique password). If not then I'd say, as a first implementation of this feature (which could be improved later), then the name of the mailbox (as in the prefix before the @) should be fed to the app as the Display Name, when more than one owner are set to that mailbox
-
for point 2, then yes, as you say the username (for login) should just remain the full mailbox email address (just that in the case of a shared one, one username will but associated to multiple passwords as valid login credentials).
-
️
