-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fetching users returns users groups with all the groups members in them #71
Comments
Hi, You may test using plugin-loki /Users groups attribute should have following syntax (value is mandatory) and only include groups the actual user is member of
If your plugin getUsers method do not return I suspect your getUsers method includes groups and do not use correct format as shown above You may also exclude groups from the response by using: Regards, |
Your issue might refer to Your are correct, skipping members.value in attributes is better The reason for including But anyhow these other members will not be included in the groups returned by /Users Jarle |
v4.1.10 have been published addressing this problem Jarle |
When fetching user (/Users), the groups' attribute is returned containing a list of all the groups the user is part of. Then each of those groups within the users returns a list of all their members.
(Not representative of a complete response, here is an example of how the payload is currently structured)
This can create large responses when the user belongs to many groups with many users (in my case, 120MB for a single user).
I propose changing https://github.com/jelhub/scimgateway/blob/master/lib/scimgateway.js#L791 to remove the
members.value
. This could be breaking for people relying on it, or it could be hidden behind a feature flag.Doing this is within the SCIM Schema specification. As outlined in section 4.1.2 https://www.rfc-editor.org/rfc/rfc7643#section-4.1.2, under the heading of groups,
This, in my eyes, would mean that members is at least an optional attribute to return on the user response payload. This is further backed up by the full user representation listed here https://www.rfc-editor.org/rfc/rfc7643#section-8.2. While the specification refers to a non-normative example, it provides an insight into what the specification authors were expecting as part of the standard.
Let me know what you think. I've already implemented the change on my fork (without the feature flag). So happy to carry this forward to a PR if you agree with the above.
Cheers,
Sam
The text was updated successfully, but these errors were encountered: