Open registration

[plusone-nick]

Also interested in this use case - if any code is shared please let me know =] I will also look into giving this a shot

[jdaviescoates]

@murgero that'd be fantastic, thanks! But, um, I can't seem to work out how to PM you on here?

[murgero]

@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.

[scooke]

@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.)

[luckow]

@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.

[scooke]

@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.

[jdaviescoates]

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!"

[jdaviescoates]

@murgero thanks, have emailed you

[girish]

@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 as my.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 .

[avatar1024]

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).

[A Former User]

@jdaviescoates
for "Open registation" read "Open registration"

[jdaviescoates]

@Hillside502 fixed, thanks

[murgero]

@jdaviescoates Is this still something you would like to discuss? I don't believe I remember getting your email

[jdaviescoates]

@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? )

[murgero]

@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"

[murgero]

@jdaviescoates

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.

[Lonkle]

I’m working on the API documentation but haven’t managed to merge anything yet but this is absolutely possible via a Cloudron Add-on as I like to call custom Cloudron web apps that enhance Cloudron specifically by using its tokens to automate tasks.

[Lonkle]

@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 as my.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 /tokens page)? Or was this before you created custom tokens?

[murgero]

@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.

[jdaviescoates]

@murgero nice!

Hopefully those section on the left/ right stack up nicely when viewing on mobile?

[Lonkle]

@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 /tokens but 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).

[luckow]

@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/

[jdaviescoates]

@luckow good that you managed to sort your use case, but I imagine a very simple Cloudron app like @murgero is developing would be a better fit for more Cloudron user

[murgero]

@jdaviescoates Yes - it's mobile friendly

[marcusquinn]

@luckow that sounds very interesting and worthy of it's own post so we can bookmark it

[Lonkle]

@luckow That’s super cool. Glad to hear it works that way with external LDAP. Thanks for sharing your story! ️

[derin]

Did anything ever come of this? IS there an app for user registration?

[jdaviescoates]

@derin no, not yet

[girish]

@derin there's an API to automatically add users - https://docs.cloudron.io/api.html#tag/Users/paths/~1users/post but no auto-registration form yet.

[A Former User]

I'm curious about this. I could see this being useful for an educational institution that uses a cloudron for student accounts.

[Sam_uk]

I'd also like open user registration (ideally with a moderation/approval step). What's needed to make it happen?

[Sam_uk]

So I need to get this working.

It seems that Croodle never made it into Cloudron?

So I need to host Croodle somewhere else, then use it to build a login page.

Is it plausible to use https://www.limesurvey.org/ instead? I already have that installled.

[Sam_uk]

@girish Just spotted that groups are not exposed in the API: https://docs.cloudron.io/api.html#tag/Users/paths/~1users/post

Are there any plans to add it?

[jdaviescoates]

@sam_uk said in Open registration:

So I need to host Croodle somewhere else, then use it to build a login page.

Croodle is irrelevant (sorry, my bad, I asked about that in this thread, but it's not related at all. Croodle is just a tool similar to Easy Appointments/ Cal.com etc that @murgero was packaging, see https://github.com/jelhan/croodle and https://www.systemli.org/poll/ )

But yeah, it'd be nice to have some sort of way for people to sign themselves up to a Cloudron and then for (Super) Admin/ User Managers to be able to approve or reject them.

I'm not sure what's actually the best way of achieving that though. Any ideas @staff?

[Sam_uk]

@jdaviescoates I'm looking at a https://form.io/ > N8N > Cloudron API workflow. No idea if that's a good way though.

All the bits are FOSS, but form.io is not available on Cloudron yet.

[fbartels]

A post of @luckow has made me interested in baserow (which is already available as an app on Cloudron). With it you can define databases and fill these through a form. It already has the ability to trigger a webhook if an entry was created.

At the moment the webhook payload cannot be freely defined, but if it would add this feature one could make a simple sign up page for Cloudron. User would be created, but sadly one needs to make multiple requests to also send out an invitation mail and to add the user to groups. But this way the admin can decide on their own if the signup should be confirmed.

Ticket is https://gitlab.com/bramw/baserow/-/issues/744

[thetomester13]

@fbartels very interesting! I also like the idea of an admin being able to adjust the payload for a webhook, but of course, that adds complexity and room for error.

Another option would be to have an n8n webhook catch Baserow's payload. From n8n (also available on Cloudron), you can format the response how you want and then make multiple API calls in order to properly create the Cloudron user.

[robi]

@thetomester13 said in Open registration:

Another option would be to have an n8n webhook catch Baserow's payload. From n8n (also available on Cloudron), you can format the response how you want and then make multiple API calls in order to properly create the Cloudron user.

Bingo!

[fbartels]

@thetomester13 But why use two applications and increase the possibility of a malfunction, when one application alone could also do the job

[Sam_uk]

@fbartels said in Open registration:

but if it would add this feature

Isn't it the case that Baserow lacks this feature? So to get something working today Baserow>N8N is the current best way? This may change in the future if Baserow gains that functionality?

[thetomester13]

@fbartels sure. One answer would be separation of concerns. Baserow isn't built to call multiple webhooks after a form submit, whereas n8n is built almost exactly for this reason (among others).

Additionally, as @Sam_uk said, this is a solution that could work right now, without having to wait for additional features being added to Baserow.

That being said, I do love the idea of being able to adjust a payload for webhooks - such flexibility!

[plusone-nick]

@plusone-nick said in 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

Better late than never https://forum.cloudron.io/topic/7546/open-registration-app-for-cloudron