SSO Username Mapping and Original Username Retention for Wikimedia Login Integration

[mariobehling]

Wikimedia requires enhanced SSO handling and username mapping to improve participant identification and Trust & Safety workflows during event registrations on Eventyay.

The requested functionality primarily concerns how usernames from SSO (e.g., Wikimedia OAuth) are pre-filled, displayed, and stored for audit and vetting purposes.

This ensures that Wikimedia usernames are applied consistently across public-facing sections of the platform, while organizers have control over whether this behavior is active through event settings.

Requirements

1. Organizer-Controlled Setting

• Introduce a new toggle in Event Settings → General / SSO Settings:
  “Use Wikimedia username as the value for the public Name field”

• When enabled:

  • Users who log in through Wikimedia SSO will automatically have their Wikimedia username applied as the value for the public “Name” field.
  • This applies across all visible contexts — user profiles, registration forms, badges, and public attendee lists.

• When disabled:

  • The “Name” field remains user-editable and behaves as standard, without pre-filling from SSO.

• The toggle works per event, giving Wikimedia events full control while preserving default behavior for others.

2. Username Pre-Fill and Display Mapping

• Upon login via Wikimedia SSO:

  • The Wikimedia username should pre-populate the “Name” field on the registration form.
  • The user may still edit the field (unless the organizer locks it in a later enhancement).
  • The name value should propagate consistently across all parts of the platform that display the participant’s name (profiles, badges, talk listings, and attendee lists).

3. Persistent Storage of Original SSO Username

• Add a permanent, non-editable field (e.g., original_sso_username) to store the username received from Wikimedia OAuth.
• This field remains tied to the user account even if the user changes their display or public name.
• Visible only to admins and organizers for Trust & Safety review; never shown to public users or included in open API responses.

4. Admin Access for Trust & Safety

• Add an admin-only view (or user detail field) displaying the original Wikimedia SSO username.
• Optionally include it in secure exports for event vetting or moderation.

5. Data Integrity and Privacy

• The original_sso_username must not be editable by the user.
• SSO re-logins must preserve the stored username (no overwrite).
• Maintain backward compatibility for all non-SSO accounts.

Possible Implementation Notes

• Extend the Wikimedia OAuth login handler to store the username claim as original_sso_username.
• Add a Boolean field use_sso_username_as_public_name to the Event model.
• Modify the registration and profile components to conditionally pre-fill the user’s display name when the organizer setting is active.
• Update Django admin and API serializers to expose the stored original_sso_username to admins only.
• Ensure consistent mapping between SSO login data and display name updates.

Testing Checklist

• Organizer toggles “Use Wikimedia username…” → platform uses SSO username as display name.
• Organizer disables toggle → normal editable “Name” field behavior restored.
• Registration form pre-fills Wikimedia username correctly.
• Display name propagates across profile, badge, and attendee lists.
• Admins can view original_sso_username in user details.
• Users cannot see or edit their original SSO username.
• Repeated SSO logins preserve stored username.
• Feature applies per event, not globally.

[hongquan]

I remember that the User model already has wikimedia_username field, though I'm not sure if it is filled with data.

[hongquan]

In the legacy website (where eventyay-xxx was still separate), the wikimedia_username is filled with data.

[mariobehling]

Ok, but that could be changed right? We need an option to display this in the CSV. Or is it also already possible?

[hongquan]

I need to test the Social Login in enext first, hopefully the username_wikimedia will also filled with data.
After that, we can add a feature to display WikiMedia username in CSV.
But first of all, the social login is lost in enext, I'm trying to recover it (I'm blocked by MediaWiki not approving my app registration yet).

[mariobehling]

The app registration is usually only necessary if you use another username. If you use the same username that you used to apply for the app then you can usually test it right away with this username (but it will not work with other usernames).

[hongquan]

After testing with the fix from PR #1230 , I can login successfully with WikiMedia but the wikimedia_username was not filled with data. There are more things to fix.

[hongquan]

Tried logging-in again (with the code from PR #1230), the wikimedia_username is now filled:

Don't know what made difference (my OAuth app is still not approved).

[ArnavBallinCode]

Update After Testing

The wikimedia_username field is already being populated by the existing adapter code. No new extraction logic is needed. A screenshot from @hongquan shows values like “Bachkhois” appearing after OAuth login using only PR #1230.

What I Misunderstood in PR #1237

I assumed the field wasn’t being populated, which led me to:

• Add unnecessary adapter hooks
• Duplicate existing username extraction logic
• Introduce an original_sso_username field without confirming its necessity

What’s Already Working (from PR #1230)

• OAuth URLs are correctly exposed
• MediaWiki OAuth flow completes successfully
• wikimedia_username populates as expected

To move forward correctly, I have a few questions:

1. Since wikimedia_username is already populating, is the additional original_sso_username field still required for Trust & Safety or audit workflows?
2. Should I wait for PR Reorganize URL pattern registration #1243 (URL restructuring) to merge before implementing the per-event toggle (“Use Wikimedia username as public Name field”)?
3. For the remaining tasks (toggle, CSV export, admin-only SSO view), should they be developed as separate PRs or combined into one?

Thanks and Apologise for all the confusion

[hongquan]

@ArnavBallinCode
1.

is the additional original_sso_username field still required

Of course not, the field name wikimedia_username is very obvious that it matches the customer needs. The rest is to check if the implementation around this field already satisfy "Trust & Safety or audit workflows", if not, we need to adjust.

2. The PR Fix: socialauth URLs were not resolved #1324 fixed the login, but Reorganize URL pattern registration #1243 still needs to be continue, because the Fix: socialauth URLs were not resolved #1324 hinted that there may be more similar bugs, caused by the messy URL registration. For the per-event toggle, you need to check if it already exist.

3. It is better that they are separated, though that it is not always possible.