Core & userId module: reload userIDs when GDPR consent changes

[dgirardi]

Type of change

• Bugfix

Description of change

This re-initializes userID modules whenever GDPR consent changes. Fixes an issue where if setConfig({userSync}) is run before setConfig({consentManagement}), the userId module would start initializing without consent and not notice when the latter is set.

[robertrmartinez]

So checking if the consent data is exactly the same is what controls the callbacks of the listeners? not just if a setConfig consentManagement occurs?

[robertrmartinez]

So the userId's are still initialized when consentManagement is not set, thus they will call their endpoint and set ID's without passing consentData right?

But if consent changes, it will call their getId again? And it is up to them to re-do the process again?

Is that correct?

[dgirardi]

Yes, that's correct (if the setConfigs are out of order). UserID already has logic to re-run getId if consent management changes, but it does not currently listen for changes, just compares the last consent it saw with what it gets when it inits. (This is to say that getId should not need to be aware that consent changed, the contract is it should always refresh, at least in theory).

The problem with waiting for the setConfig({consentManagement}) is that:

• we try to resolve both userId and consent before any auction happens, so there's no clear cutoff where we can say "by now, all configs should have been set". This was changed relatively recently, it's no longer true that userId/gdpr only happen at the time of requestBids.
• currently you can include the gdpr module and never activate it, equivalent to not including it. If we say "when the gdpr module is included, wait for setConfig({consentManagement}), anyone who is not setting it would be left dangling waiting for it until some timeout expires. I don't know if this is preferable.

[robertrmartinez]

thanks for the quick fix! GDPR and User ID's is always a lot of fun!