13 comments

  • tcrow 192 days ago

    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?

    • system2 192 days ago

      Wouldn't be more appropriate to describe this as a drupal plugin / extension?

      Also, why would a extension / plugin cost monthly for CRUD type application? What kind of support do you provide?

      • Risse 192 days ago

        The term that Drupal uses for these "full website" packages are "distributions": https://www.drupal.org/docs/8/distributions

        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)

      • headcanon 192 days ago

        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.

        Edit: I meant Discourse. and I also answered my own question: https://github.com/unicodeveloper/awesome-opensource-apps

        • eeZah7Ux 192 days ago

          +1, a repository with proper indexing would be nice, but also a place where people can request such applications or find contributors.

          • the_common_man 192 days ago

            search for awesome-selfhosted. one of the most comprehensive lists

          • kplex 192 days ago

            Does the demo reset? Clicking around trying stuff resulted in the landing page showing not found?

            Worth disabling the https://demo.pinomembers.com/admin/structure/member/settings page for the demo perhaps?

            • Risse 192 days ago

              Yes, the site should reset every 15 minutes, please try again soon.

            • joekrill 192 days ago

              Not to be confused with the relatively well-known JavaScript logging library called Pino.

              • jilles 192 days ago

                It always baffles me when people don't do their research before releasing a project / product. A few months ago there was a guy releasing his own language called Flux...

                • james_s_tayler 192 days ago

                  Or the Japanese chocolate.

                • h1d 192 days ago

                  In what format are the users stored? Is it just another custom database schema?

                  It's kind of pointless when it can't be integrated with bunch of other infrastructures that support common protocols like LDAP.

                  • masha_sb 192 days ago

                    1. anything similar in python?

                    2. what is so special, about yet another membership management solution?

                  • sigfubar 192 days ago

                    > Pino is an open source web app built on Drupal

                    closes tab

                    I do love me a hint of scandal, but the whole "thou shalt not BDSM in your spare time" thing is a major turnoff.

                  • funkaster 192 days ago

                    > managing our associations' members with a spreadsheet program just wasn't suitable and we needed something better and easier

                    ok... what about not reinventing the wheel and using something like LDAP[0] and one of its many, many UIs? How is this different from all the other solutions?

                    [0]: https://en.wikipedia.org/wiki/Lightweight_Directory_Access_P...

                    • h1d 192 days ago

                      I have been using OpenLDAP to manage users for like 10 years but what GUI/web based tool do you suggest for managing its data?

                      The only non complicated solution looks to be PHPLdapAdmin which I use but it is pretty much abandoned and a fork is keeping it alive.

                      • funkaster 192 days ago

                        Here's a new one (that I haven't personally used): https://github.com/kakwa/ldapcherry

                        • h1d 192 days ago

                          You said many many UI but that one looks to be very basic which anyone can build in a day.

                          I really find it hard to manage LDAP without a intuitive clean UI and wonder why there aren't much demand for it.

                          • kakwa_ 191 days ago

                            Not really in a day.

                            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.

                            • funkaster 192 days ago

                              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.

                            • kakwa_ 191 days ago

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

                        • sucrose 192 days ago

                          This site can’t be reached: demo.pinomembers.com unexpectedly closed the connection.

                          • csixty4 192 days ago

                            Is the domain name a play on GoMembers?

                            • Risse 192 days ago

                              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.

                            • kowdermeister 192 days ago

                              User / pass doesn't work.

                              • Risse 192 days ago

                                Heh, someone decided to be funny and changed it. It should be fixed, please try again.

                              • mushufasa 192 days ago

                                looks like bulma css