Fix bug with lowercasing #15

Open
Kidswiss wants to merge 1 commits from Kidswiss/bottin:fix/lowercase into main
Contributor

This fixes some ldap queries not working due to case differences.

This fixes some ldap queries not working due to case differences.
Kidswiss added 1 commit 2022-02-10 19:54:18 +00:00
continuous-integration/drone/pr Build is passing Details
ae44c29fc3
Fix bug with lowercasing
This fixes some ldap queries not working due to case differences.
Owner

This looks like something that could break on existing databases, for instance if some objects were written with a path that contains uppercase characters. Also I know this is probably not the only issue with case sensitivity in Bottin, because we don't understand the LDAP spec very well. I think globally we should only do things that make Bottin better compliant to the spec -- it might be the case with this PR, but before I merge, I would like to make sure of the following things:

  • Is it in the LDAP spec that all objects must have lowercase DN ?

  • Is it in the LDAP spec that if I create an object with some uppercase characters in the path, they should be converted to lowercase when storing ?

This looks like something that could break on existing databases, for instance if some objects were written with a path that contains uppercase characters. Also I know this is probably not the only issue with case sensitivity in Bottin, because we don't understand the LDAP spec very well. I think globally we should only do things that make Bottin better compliant to the spec -- it might be the case with this PR, but before I merge, I would like to make sure of the following things: - Is it in the LDAP spec that all objects must have lowercase DN ? - Is it in the LDAP spec that if I create an object with some uppercase characters in the path, they should be converted to lowercase when storing ?
Owner

Actually, I think what we want would be more like allowing objects to be stored with uppercase characters in the path, but having a case-insensitive way of searching them. However I'm not sure we can really do this with the Consul KV store that is case-sensitive. I'm not yet convinced that the solution from this PR which is to make everyting lowercase is the correct solution, I think we should have more discussion about this (also I'm not really confident in my current understanding of LDAP and of what Bottin actually does). We have a Matrix channel to discuss Bottin developpement at #bottin:deuxfleurs.fr, I'll just throw the issue there and see where it goes. Feel free to join us on the Matrix room @Kidswiss :)

Actually, I think what we want would be more like allowing objects to be stored with uppercase characters in the path, but having a case-insensitive way of searching them. However I'm not sure we can really do this with the Consul KV store that is case-sensitive. I'm not yet convinced that the solution from this PR which is to make everyting lowercase is the correct solution, I think we should have more discussion about this (also I'm not really confident in my current understanding of LDAP and of what Bottin actually does). We have a Matrix channel to discuss Bottin developpement at `#bottin:deuxfleurs.fr`, I'll just throw the issue there and see where it goes. Feel free to join us on the Matrix room @Kidswiss :)
Owner

Hi @Kidswiss,

Following LX messages, I would like to add you are the first one (excluding members of Deuxfleurs) to show interest in Bottin: this might be a turning point in its development. Until now, our development were driven only by our internal needs. But your PRs force us to think further than this simple goal. This is a good thing, because it seems that Bottin may fulfill needs outside of Deuxfleurs, and we might be able to foster a community around our software. In the long term, it could lead to better maintained software, less burden on our teams, and help autonomize people and organizations in the digital field. Also, if we know that there is enough interest in these solutions, we can also envision applying for a grant similar to what we have done for garage/or seek some private funding.

From this observation, it could really help us if we could know how you discovered Bottin, what is the problem you want to solve, what tests you have done, what was hard to do when deploying it, do you plan to use it in production, why do you prefer Bottin compared to openldap/keycloack/389/etc, what is your experience with LDAP, etc. The reason these questions are important to us is because we want to keep consistent software, so we need abstract/long term goals. This PR will, at least, change our goal from "developping something that work for us" to "implementing as close as possible a specific subset of LDAP (to be defined)". So we might have to define what subset we want, and how we want to do it (eg. how we handle backward compatibility with our current production system), and it would be better to have you in the loop.

If Matrix (the decentralized chat protocol) is not your thing, we can also exchange by email (we do not have yet a mailing list for bottin but you can write to garagehq <at> deuxfleurs.fr) or any other mean of communication that you are comfortable with.

And if you were planning only a one-shot contribution just because you tested Bottin, found some bugs, wanted to contribute fixes, but do not plan to use it or work more on it, please give us some times to discuss internally if we want to invest time to better follow the LDAP specification, and how we can conduct this work to not break our running services.

Hi @Kidswiss, Following LX messages, I would like to add you are the first one (excluding members of Deuxfleurs) to show interest in Bottin: this might be a turning point in its development. Until now, our development were driven only by our internal needs. But your PRs force us to think further than this simple goal. This is a good thing, because it seems that Bottin may fulfill needs outside of Deuxfleurs, and we might be able to foster a community around our software. In the long term, it could lead to better maintained software, less burden on our teams, and help autonomize people and organizations in the digital field. Also, if we know that there is enough interest in these solutions, we can also envision applying for a grant similar to what we have done for [garage](https://garagehq.deuxfleurs.fr)/or seek some private funding. From this observation, it could really help us if we could know how you discovered Bottin, what is the problem you want to solve, what tests you have done, what was hard to do when deploying it, do you plan to use it in production, why do you prefer Bottin compared to openldap/keycloack/389/etc, what is your experience with LDAP, etc. The reason these questions are important to us is because we want to keep consistent software, so we need abstract/long term goals. This PR will, at least, change our goal from "developping something that work for us" to "implementing as close as possible a specific subset of LDAP (to be defined)". So we might have to define what subset we want, and how we want to do it (eg. how we handle backward compatibility with our current production system), and it would be better to have you in the loop. If Matrix (the decentralized chat protocol) is not your thing, we can also exchange by email (we do not have yet a mailing list for bottin but you can write to `garagehq <at> deuxfleurs.fr`) or any other mean of communication that you are comfortable with. And if you were planning only a one-shot contribution just because you tested Bottin, found some bugs, wanted to contribute fixes, but do not plan to use it or work more on it, please give us some times to discuss internally if we want to invest time to better follow the LDAP specification, and how we can conduct this work to not break our running services.
Author
Contributor

Hi Everyone

Sorry for the late answer I seem to not have gotten any mail notifications from this Gitea instance :(

As for the whole lower-case issue: at least Vault and Grafana also had a few issues with them, but not for the DN but rather attributes used for filtering like memberof (memberOf respectively). But all in all it works really great :)

I found it simply by googling "cloud native ldap" as I was fed up with my previous solution (opendj) hogging so much memory. I'm mainly using it in my homelab environment.

As far as I know of the LDAP specs is that it's supposed to be case-insensitive. So (&(memberOf=blah)) should yield the same result as (&(memberof=blah)). But it seems from my experience that this issue is a bit more nuanced if the App that does the query is somewhat case-sensitive in evaluating the rules (Vault and Grafana so far...).

I'm planning on just using bottin on my homelab and thought it would be useful to contribute if I found some bugs. I'm joining the Matrix, if you want to bounce some ideas though :)

Best Regards

Hi Everyone Sorry for the late answer I seem to not have gotten any mail notifications from this Gitea instance :( As for the whole lower-case issue: at least Vault and Grafana also had a few issues with them, but not for the DN but rather attributes used for filtering like memberof (memberOf respectively). But all in all it works really great :) I found it simply by googling "cloud native ldap" as I was fed up with my previous solution (opendj) hogging so much memory. I'm mainly using it in my homelab environment. As far as I know of the LDAP specs is that it's supposed to be case-insensitive. So `(&(memberOf=blah))` should yield the same result as `(&(memberof=blah))`. But it seems from my experience that this issue is a bit more nuanced if the App that does the query is somewhat case-sensitive in evaluating the rules (Vault and Grafana so far...). I'm planning on just using bottin on my homelab and thought it would be useful to contribute if I found some bugs. I'm joining the Matrix, if you want to bounce some ideas though :) Best Regards
All checks were successful
continuous-integration/drone/pr Build is passing
This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/bottin#15
No description provided.