Skip to content

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)

image

How to set up and validate locally (Warning:Very involved setup necessary if not already in place)

  1. Enable HTTPS for local GDK
  2. Setup Local fake SAML IdP
  3. Add the SAML IdP for one of your seeded groups (e.g. twitter)
  4. Add domain restrictions to the same group e.g. notarealdomainanywayx1337x69.com

On branch master:

  1. Attempt to sign up for the group with the group's SAML link eg https://gdk.test:3443/groups/twitter/-/saml/sso with user1 : user1pass in SAML IdP
  2. See a new audit event for Added user access as Developer on https://gdk.test:3443/admin/audit_logs for User One after sign up

On branch sf/bugfix/GL370169-audit-events-on-domain-restrictions:

  1. Attempt to sign up for the group with the group's SAML link eg https://gdk.test:3443/groups/twitter/-/saml/sso with user2 : user2pass in SAML IdP
  2. 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.


This description IN PART was generated for revision a0c01a43 using AI

Edited by Sam Figueroa

Merge request reports

Loading