I feel like this needs a bit more polish before you start telling users it is ready. I see double menus, random logouts, and a bare bones feature set. Basically just a list of users with ability to send emails?
The monthly cost is mainly for support, hosting and email delivery. The support includes security updates for server and Drupal libraries, customer support via email and helping with import / export of member data (of course, due to GDPR and sensitive contact information, a processing agreement has to be signed and agreed upon)
Is there a repository (like an awesome-* list) of open-source self-hosted appliance apps like this? I'm sure there's an awesome-drupal list, but I'm thinking more like a list that might also include this and Discord.
You could probably hack something in day, hardcoding things like schemas, fields, and things like that.
But having something that is reusable requires more work than a day.
Just as an example, even handling ssl/tls is far from trivial (plain ssl vs startls, with certificate validation or not, with a custom CA or not), it took me easily a few days to understand the options python-ldap provides, expose the options in a clear manner in the config file, deal with errors to provide meaningful logs and properly test everything.
my guess is that many people/orgs they don't use LDAP directly: it's used as the backend to manage permissions, groups, metadata, etc. They prob use their own system that relies on LDAP to manage the details of their org.
And if you are a user, a new version with numerous fixes (including security ones) was just released.
Disclaimer: I'm the author of ldapcherry.
My motivation was indeed that the go to solution is phpLdapAdmin, which is basically ldapsearch/modify in a web UI. It's a bit too rough and open for general users IMHO.
Hopefully ldapcherry provides something simpler and a bit prettier for the users.
Also, it's quite common for IT environments to have an ldap server (OpenLdap or 389 directory) and Active Directory (or samba 4 in AD mode). A secondary goal was to manage both at the same time.
ldapcherry works both with AD and ldap, creating/modifying a given user in both directories. And it can actually be extended to support other backends.
A third motivation was to be able to manage "roles". It's quite common to have ldap/AD groups triggering access to one specific resource (ssh into prod servers with or without root access, access to the git repositories, access to log indexer, etc).
But requesting each group individually is a pain, and you end-up with a wild variety of groups set even between members of a given team. That's why ldapcherry has a notion of "roles" (group of groups): for example you click the "sysadmin" role and it will put you in the groups that grant you access to ssh, monitoring, logs, etc.
That being said, it has some limitations:
* The groups/roles are statically defined in a yaml file, so it's not really dynamic
* There is no real tooling to audit/normalize the backends content (for example after a role definition change)
* There is no mechanism to temporary delegate a role to a person
* There is only one "big" admin group, no notion of "this role can be set by this group, and this other role by this other group"
* There is no request/notification mechanism when a user requests approval for being member of a role
* I'm not completely sure how I could handle forgotten password for users more cleanly
* I'm not sure how the UI would look with hundreds of roles (probably not great since all roles will be displayed...)
These are clear limitations that makes ldapcherry not suited for large organizations, but it should work OK for small ones.
Also, right now, ldapcherry is mostly stateless. It doesn't need a DB, you just configure it and plug it to your ldap/AD, which means it's fairly simple to deploy. If I were to implement the previously mentioned items, it would probably require a DB, which would increase complexity, and I'm reluctant to do so. Maybe a pluggable module could do the trick, but I would have to create an API for such module in the existing code.
Lastly I'm a lone developer with limited skills, and this is a side project, so I don't always have the motivation/time to work on it.
I think these few explanations kind of illustrate why there is no decent ldap web UI ^^.
Hah, actually not, never heard of GoMembers before. I of course wanted to have as short url as possible, but "pino" with all common TLDs were taken. So putting "members" to the end seemed to make sense to me.