Open registration
-
@jdaviescoates Why do you want to do this? The apps available can by-and-large already allow a user to register for them. Letting others register under your Cloudron sounds similar to sharing your password with friends and family to share your Netflix. Why would others need to access your cloudron? Genuine question. (I guess my concern is increasing the load by more users without them paying for it, thereby possibly decreasing overall performance for those of us who do pay.)
-
@scooke eg. a use case is an open source community that uses a cloudron instance with some apps. They offer the apps to their community members. To have a consistence user management, it makes sense to have it in the ldap of Cloudron instead of in the user management of each individual application. If you only have 10 or 20 members it's not a problem to delegate the user creation to a user with the admin role. For all other numbers an open registration fits.
-
@luckow I guess you are talking about the Enterprise Cloudron? I'm still trying to understand the situation you describe. My understanding is that Cloudron allows the paying customer (admin) to manage users, thus, the admin can create users (which are email based?) who can then access apps which the admin has created. When I look at https://cloudron.io/console.html#/userprofile?view=subscriptions I don't see any options for more than one admin, which is what it sounds like the op is asking for, unless that is what the Enterprise version is for. Even in the context you describe, it doesn't make sense to allow everyone/anyone admin access to your Cloudron account to then start installing and running any number of cloudrons. *which made me pause, because from what I understand any one cloudron can only be run under one domain. Why would you allow X number of users to access your my.domain.com cloudron to start installing whatever? How would you even monitor it to ensure no one is using more resources than they should? And if the answer is that they would not have access to admin1's cloudron but their own, then shouldn't they just make their own account? Or is it the idea that open source communities are exempt from paying (an option many other services make available)?
In terms of consistent user management, that is exactly what Cloudon already offers. The one admin user can create X number of users, such as admin@domain.com, user1@domain.com, user2@domain.com, and then even group them. Then, when creating an app, the admin user can then allow users, or users based on groups, access to the admin-created app, without the need for each user to have to manually create their own login for each app (for the most part, some of the apps aren't managed by the cloudron LDAP but manages users within itself).
But I suppose user1@domain.com might not like the admin-created username and prefers userA@domain.com, and thus allowing them to register themselves as such is preferable to trying to communicate to the admin. And then this cloudron-created user can use the LDAP advantage for signing into other apps too, using their preferred userA@domain.com. If THIS is what the OP is talking about, then I understand the nature of the request: Allowing a user to register themselves as a user within the cloudron LDAP without giving them any admin access.
Thank for reading all that. I'm trying to understand better.
-
Yes, I just want members of my company/ team to be able to register themselves (and then myself as an the admin to approve their registration request) rather than myself having to register them individually so that I can just say say:
"hey, I've set-up all these cool apps for us to use using this brilliant platform called Cloudron. All you have to do is register at my.mydomain.coop and then once I've approved your registration you'll be able to use those same credentials to login to chat.mydomain.coop, tasks.mydomain.coop, files.mydomain.coop etc too, it rocks! enjoy!"
-
@murgero Let me know if you need something from the Cloudron side. I guess it can be a separate web app that can be installed at say
register.mydomain.com. It can then take an access token (this view is currently "hidden". access it asmy.domain.com/#/tokens) and a Cloudron end point. You should then be able to make calls to create user using https://cloudron.io/documentation/api/#/paths/~1users/post . -
Has there been any update on this by any chance? It feels like a super useful feature to have (if well implemented not to get spammed by million subscribers).
-
@jdaviescoates
for "Open registation" read "Open registration" -
@Hillside502 fixed, thanks
-
@jdaviescoates Is this still something you would like to discuss? I don't believe I remember getting your email
-
@murgero you replied 3 times in that email thread
And then we chatted a little on Matrix, but struggled to find a time we could discuss further...
How is that Croodle package coming along?
(it seemed to already be working well when I tested your test app at https://croodle.urgero.org/ 22 days ago - what's left to get it into the app store?
) -
@jdaviescoates said in Open registration:
How is that Croodle package coming along?
Croodle is working fine - just needs appstore approval!
Let's reconnect on Matrix
I'd like to discuss again now that work has "calmed down" -
Obviously this doesn't completely open registration but allows you to look at a list of requested accounts and approve them. This is the frontend for normal users. I plan on making an admin portal soon enough.
-
-
@girish said in Open registration:
@murgero Let me know if you need something from the Cloudron side. I guess it can be a separate web app that can be installed at say
register.mydomain.com. It can then take an access token (this view is currently "hidden". access it asmy.domain.com/#/tokens) and a Cloudron end point. You should then be able to make calls to create user using https://cloudron.io/documentation/api/#/paths/~1users/post .I’ve only ever been able to get an access token using the API endpoint giving it user admin credentials. What is taking an access token from this “hidden” page
/tokenspage)? Or was this before you created custom tokens? -
-
@murgero nice!
Hopefully those section on the left/ right stack up nicely when viewing on mobile?
-
@murgero said in Open registration:
@Lonk If you are an admin on the cloudron instance, just go to your profile https://my.example.com/#/profile and scroll down to "API Tokens" to create an API token.
Yes, but the way @girish explained it didn’t sound like doing it manually like how you instructed, so I wondered what he meant. I really don’t know what he meant by the “app could take a token” from
/tokensbut I’d never heard of that endpoint. I’m guessing it’s just the old one that was used to create custom api tokens before the current system (which uses a different URL). -
@avatar1024 Sorry for beeing a little bit verbose
CMS Garden held a (virtual) Unconference two weeks ago. One of our biggest issues was self registering attendees into our LDAP. Thanks to the external LDAP connector to Univention Corporate Server (UCS) in Cloudron we used the following setup:
UCS as our central user management (LDAP) with self registration.
Cloudron as our primary solution for our apps. The Cloudron instance was connected through the external LDAP connector.We had some other cool apps lying around
BBBatscale is a loadbalancer for BigBlueButton instances and capable of connecting against a LDAP server. Yep - users in UCS are authorized users in BBBatscale.Openstreamingplatform as our twich alternative to embed the streams from different BBB rooms. (But without any knowledge of LDAP users).
In a slightly different setup we use UCS to be the central user management to different Cloudron instances. But in this setup without self registration.
Good news: there is a possibility today to have a central LDAP user management with many Cloudrons. And if you need it, with a self registration kind of "portal".
Read more
https://www.univention.com/downloads/download-ucs/
https://www.univention.com/blog-en/2020/05/register-your-own-account-new-self-service-for-suse-and-ucs/
