starred/pocket-id-pocket-id-2
1
0
Fork 0
mirror of https://github.com/pocket-id/pocket-id.git synced 2025-12-09 22:52:58 +03:00
Code Issues 116 Packages Projects Releases 10 Wiki Activity

🚀 Feature: Support addition LDAP group membership attributes #358

New Issue
Closed
opened 2025-10-09 16:41:50 +03:00 by OVERLORD · 5 comments
OVERLORD commented 2025-10-09 16:41:50 +03:00
Owner
Copy Link

Originally created by @koalaeagle on GitHub.

Originally assigned to: @kmendell on GitHub.

Feature description

I have recently setup pocket id with LDAP sync, and it is working great!

However, I did run into one issue in my environment. Group membership mappings were not working correctly. Looking through the source code, I found that the logic is querying for the "member" attribute of each group. However, my LDAP server (glauth) appears to be using the attribute "uniqueMember".

As a quick and dirty test, I replaced the two relevant occurrences of "member" (in searchAttrs and groupMembers declaration) in backend/internal/service/ldap_service.go and built the docker container. This immediately fixed my issue.

I am not sure how to best address this, but understand that due to the nature of LDAP there can be inconsistencies with mappings. If there aren't too many different commonly used identifiers for group members, perhaps it is worth implementing logic to discover what attribute is in use? Alternatively, this could be implemented as a configuration option like the other attribute mappings.

Pitch

This feature would ensure that group mappings work in different LDAP implementations/environments.

Originally created by @koalaeagle on GitHub. Originally assigned to: @kmendell on GitHub. ### Feature description I have recently setup pocket id with LDAP sync, and it is working great! However, I did run into one issue in my environment. Group membership mappings were not working correctly. Looking through the source code, I found that the logic is querying for the "member" attribute of each group. However, my LDAP server (glauth) appears to be using the attribute "uniqueMember". As a quick and dirty test, I replaced the two relevant occurrences of "member" (in searchAttrs and groupMembers declaration) in backend/internal/service/ldap_service.go and built the docker container. This immediately fixed my issue. I am not sure how to best address this, but understand that due to the nature of LDAP there can be inconsistencies with mappings. If there aren't too many different commonly used identifiers for group members, perhaps it is worth implementing logic to discover what attribute is in use? Alternatively, this could be implemented as a configuration option like the other attribute mappings. ### Pitch This feature would ensure that group mappings work in different LDAP implementations/environments.
OVERLORD added the feature label 2025-10-09 16:41:50 +03:00
OVERLORD commented 2025-10-09 16:41:53 +03:00
Author
Owner
Copy Link

@kmendell commented on GitHub:

It is working as expected for the member attribute i cant not say for certain for @koalaeagle use case though.

@kmendell commented on GitHub: It is working as expected for the `member` attribute i cant not say for certain for @koalaeagle use case though.
OVERLORD commented 2025-10-09 16:41:53 +03:00
Author
Owner
Copy Link

@koalaeagle commented on GitHub:

This worked perfectly for me!

Steps taken:

  1. Switched to ghcr.io/pocket-id/pocket-id:development image
  2. Tested a sync with defaults - groups reset back to 0 members
  3. Updated "Group Members Attribute" from member (default) > uniqueMember (based on glauth attribute)
  4. Tested another sync, group membership populated as expected based on LDAP server group mappings
  5. Tested an application restricted via group membership and all working as expected
@koalaeagle commented on GitHub: This worked perfectly for me! Steps taken: 1. Switched to `ghcr.io/pocket-id/pocket-id:development` image 2. Tested a sync with defaults - groups reset back to 0 members 3. Updated "Group Members Attribute" from **member** (default) > **uniqueMember** (based on glauth attribute) 4. Tested another sync, group membership populated as expected based on LDAP server group mappings 5. Tested an application restricted via group membership and all working as expected
OVERLORD commented 2025-10-09 16:41:53 +03:00
Author
Owner
Copy Link

@kmendell commented on GitHub:

@koalaeagle I opened a PR here https://github.com/pocket-id/pocket-id/pull/236 , can you verify this is what you changed and is what your were asking for?

@kmendell commented on GitHub: @koalaeagle I opened a PR here https://github.com/pocket-id/pocket-id/pull/236 , can you verify this is what you changed and is what your were asking for?
OVERLORD commented 2025-10-09 16:41:54 +03:00
Author
Owner
Copy Link

@kmendell commented on GitHub:

@stonith404 Should be good to merge this in if the code looks good to you.

@kmendell commented on GitHub: @stonith404 Should be good to merge this in if the code looks good to you.
OVERLORD commented 2025-10-09 16:41:56 +03:00
Author
Owner
Copy Link

@stonith404 commented on GitHub:

You can test it with the ghcr.io/pocket-id/pocket-id:development image.

@stonith404 commented on GitHub: You can test it with the `ghcr.io/pocket-id/pocket-id:development` image.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
breaking
bug
documentation
feature
needs more upvotes
open to pull requests
pull-request
Mirrored from GitHub Pull Request
No Label feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pocket-id-pocket-id-2#358
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?