Fix false audit event for non persisted members
What does this MR do and why?
Fixes a bug where a false audit event was logged when attempting to add a member to a group with domain restrictions in place.
The bug was caused by the member not being persisted when the domain restrictions were in place, resulting in an un-persisted member being audited.
This MR fixes the bug by checking if the member is persisted before logging the audit event.
Screenshots or screen recordings
Bug behavior: (Audit event hints at un-persisted member)
How to set up and validate locally (Warning:Very involved setup necessary if not already in place)
- Enable HTTPS for local GDK
- Setup Local fake SAML IdP
- Add the SAML IdP for one of your seeded groups (e.g.
twitter
) - Add domain restrictions to the same group e.g.
notarealdomainanywayx1337x69.com
On branch master
:
- Attempt to sign up for the group with the group's SAML link eg
https://gdk.test:3443/groups/twitter/-/saml/sso
withuser1
:user1pass
in SAML IdP - See a new audit event for
Added user access as Developer
on https://gdk.test:3443/admin/audit_logs forUser One
after sign up
On branch sf/bugfix/GL370169-audit-events-on-domain-restrictions
:
- Attempt to sign up for the group with the group's SAML link eg
https://gdk.test:3443/groups/twitter/-/saml/sso
withuser2
:user2pass
in SAML IdP - No longer see any new added audit events for
Added user access as Developer
on https://gdk.test:3443/admin/audit_logs after sign up
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
This description IN PART was generated for revision a0c01a43 using AI
Edited by Sam Figueroa