Open registration
-
Also interested in this use case - if any code is shared please let me know =] I will also look into giving this a shot
-
@murgero that'd be fantastic, thanks! But, um, I can't seem to work out how to PM you on here?
-
@jdaviescoates Oh PMs must have been disabled or something, you can find my contact info on https://urgero.org
Use whatever is comfortable for you. Many contact options to choose from.
-
@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?
