[pretix as OpenIDConnect client OIDC] Customer Account Anonymization does not delete their unique identifiers

[Wikinaut]

[UPDATE]
A workaround (manual renaming of the inactive pretix-internal identifier to identifier.OLD) is described below #3921 (comment) YMMV.

Problem and impact

tl;dr
Bug: Customer Account Anonymization does not delete their unique identifier.

Long version:

• I succesfully added Customer Account via OIDC SSO (ok).
• I found, that the "name" field was not filled correctly, because I missed to setup the name field in the SSO admin panel.
• A second SSO-login did not re-fill the name field from the SSO provider (this can be understood, but perhaps should be filed as separate issue.)

Problem:

As Admin, I wanted to delete my Customer Account, but there is not function to delete, only a function to "anonymize" an account, what I did.

Expected behaviour

The expected behaviour is:

That anonymization also(!) anonymizes the unique indentifier (here from SSO "sub") in order to allow a fully new user account creation.

But this was apparently not the case!

A new SSO Login - I expected a NEW customer account to be created - failed surprisingly with the message:

Login was not successfull: identifier not unique

tl;dr
Bug: Customer Account Anonymization does not delete their unique identifier.

Steps to reproduce

See above

Screenshots

Link

No response

Browser (software, desktop or mobile?) and version

No response

Operating system, dependency versions

No response

Version

2024.1.0

[raphaelm]

Hmm, yes, this is not good the way it is. Changing the identifier, however, is also not good. Will need to think about this - currently I'm not sure why we went with hashed uids in the first place, there was some reason but I can't remember it currently.

[Wikinaut]

From privacy aspects (not my current problem of being unable to log-in as myself, what is the case at the moment - I have to try to change my "old", still blocking "sub" in the database), an anonymising operation should clean up also the sub or other external reference in the pretix databases. This is my view.

It' s not visible any longer, but present (somewhere under the hood).

[Wikinaut]

The former (1) customer account reference (2) looks to be gone, but is not. It is blocking to open a new account.

[Wikinaut]

Hmm, yes, this is not good the way it is. Changing the identifier, however, is also not good. Will need to think about this - currently I'm not sure why we went with hashed uids in the first place, there was some reason but I can't remember it currently.

In my view, when email address and name are deleted as appears to be the case at the moment, I am interested to learn, why the unique reference (sub aka Referenz) is not - this sub is the key to scrutizine, the magic unique item.....

In my view, it is the most "evil" item of all the sso data - which need to be deleted in any case when "anonymisung". Pretix still has its own Kundennummer, that's fine enough to "bind" the bookings to that person.

As mentioned: I am interested to learn and to understand, why the identifier is still present and, my problem, blocking.

If and only if the blocking is the important part, for example to avoid impersonication, that would be probably valid reason. I would like to learn, why exactly (case study).

[raphaelm]

The sub is deleted, it is not kept under the hood, but the pretix-side customer ID in this case isn't random, but includes a hash of the sub. This was necessary for some reason but I currently don't remember what it was.

[Wikinaut]

The sub is deleted, it is not kept under the hood, but the pretix-side customer ID in this case isn't random, but includes a hash of the sub. This was necessary for some reason but I currently don't remember what it was.

Ok.

But in that way it still prevents me from creating a new account via my credentials from that provider.

As I am a MySQL/MariaDB person: could you be so kind to post here the Postgresql code to delete that specific entry manually?

[Wikinaut]

#WORKSFORME:

Workaround:

I renamed that ìdentifier in the database to identifier.OLD.

Now I can come back to pretix with my former SSO-user and got indeed the same ``ìdentifier```(from SSO-Accountcreation) and the old identifier is not blocking anymore:

[Wikinaut]

Dear @raphaelm , if you prefer to close my issue report: it will be fine for me.
On the other hand, I think, it describes an interesting observation which perhaps should be fixed.

One solution as proposed: during anonymization: add .OLDto the ``ìdentifier```.

sudo -u pretix pgsl -d pretix;
update public.pretixbase_customer set identifier = '5E76167.OLD' where identifier = '5E7616';

results (after that user came back to pretix) in: