You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off, thank you for the amazing work on this wrapper — I'm very happy with it!
Recently, after someone accidentally deleted our LDAP user in CT, I decided to take the opportunity to upgrade to v3 of your wrapper. However, I encountered some challenges regarding the required permissions for the LDAP user.
Following the principle of least privilege, I aimed to grant only the minimal permissions necessary for functionality. Unfortunately, determining the exact set of permissions has been quite tedious, largely due to the complexity of CT's permission system.
Additionally, I noticed something concerning:
If I successfully log in via LDAP with any CT user, then remove some of the permissions from the LDAP CT user (CT_USER) for testing, I can still log in via LDAP with any CT user. This behavior suggests there might be some form of caching involved.
Could you please clarify the exact permissions required for the LDAP user in CT (CT_USER) to function correctly with v3? I wasn’t able to find this information in the documentation.
Thank you for your assistance!
The text was updated successfully, but these errors were encountered:
I'm also very interested in an guideline, which permissions are needed exactly.
@sebamomann regarding the caching. There is an environment variable CACHE_LIFETIME_MS which is set to 300000 by default. This means cache is 5 minutes.
@sebamomann regarding the caching. There is an environment variable CACHE_LIFETIME_MS which is set to 300000 by default. This means cache is 5 minutes.
This is correct, BUT it doesn't apply to authentication. Auth is always done against the REST API directly, since the hashed passwords cannot be queried anyway and are therefore out of scope.
Caching applies only for users, groups and their respective relations.
Regarding the overall issue:
To be honest, I can only tell you with certainty which REST calls the tool performs against the ChurchTools API: GET /groups/members (mappings of persons/groups) GET /person/masterdata (group types for LDAP object classes) GET /persons GET /groups POST /login (for auth, obviously, body contains auth JSON)
API documentation is available at https://your-church.church.tools/api.
The precise set of privileges required for these API calls to work depends on the code of ChurchTools and (at least partially) the structure of your church's data in CT.
These are the privileges I use for the API user, without any guarantee whatsoever about being the minimal viable set:
Maybe that helps.
I keep this issue open in case someone wants to contribute a precise documentation based on the CT code or trial-and-error experiments.
Hi,
First off, thank you for the amazing work on this wrapper — I'm very happy with it!
Recently, after someone accidentally deleted our LDAP user in CT, I decided to take the opportunity to upgrade to v3 of your wrapper. However, I encountered some challenges regarding the required permissions for the LDAP user.
Following the principle of least privilege, I aimed to grant only the minimal permissions necessary for functionality. Unfortunately, determining the exact set of permissions has been quite tedious, largely due to the complexity of CT's permission system.
Additionally, I noticed something concerning:
If I successfully log in via LDAP with any CT user, then remove some of the permissions from the LDAP CT user (CT_USER) for testing, I can still log in via LDAP with any CT user. This behavior suggests there might be some form of caching involved.
Could you please clarify the exact permissions required for the LDAP user in CT (CT_USER) to function correctly with v3? I wasn’t able to find this information in the documentation.
Thank you for your assistance!
The text was updated successfully, but these errors were encountered: