add support for TCF2 #4911
add support for TCF2 #4911
Conversation
jsnellbaker
requested review from
harpere,
bretg,
jaiminpanchal27 and
mkendall07
|
This pull request introduces 1 alert when merging e114843 into bd5408c - view on LGTM.com new alerts:
|
| } else if (inASafeFrame() && typeof window.$sf.ext.cmp === 'function') { | ||
| callCmpWhileInSafeFrame('getConsentData', callbackHandler.consentDataCallback); | ||
| callCmpWhileInSafeFrame('getVendorConsents', callbackHandler.vendorConsentsCallback); | ||
| utils.logInfo('Detected Prebid.js is encased in a SafeFrame and CMP is registered, calling it now...'); |
There was a problem hiding this comment.
Hi @jaiminpanchal27 , Could you please add a comment in code about "only TCF1 is handled in the case of SafeFrame and in case of TCF2 post-messages will do the job and sf.ext.cmp is not required." Everyone looking at the code may not be aware of the new change :-)
There was a problem hiding this comment.
Hi @pm-harshad-mane
Thanks for this feedback. I did add a comment here to note it was only used for the v1 spec. However, I also updated the conditional to check if the cmpVersion variable was equal to 1 (which should be detected from the findCMP() logic); this is to ensure it's only used for the v1 spec.
There was a problem hiding this comment.
Cool, Thanks @jaiminpanchal27
|
This pull request introduces 1 alert when merging cd5ae8b into 4de8941 - view on LGTM.com new alerts:
|
| if (success) { | ||
| if (tcfData.eventStatus === 'tcloaded' || tcfData.eventStatus === 'useractioncomplete') { | ||
| cmpSuccess(tcfData, hookConfig); | ||
| } else if (tcfData.eventStatus === 'cmpuishown' && tcfData.tcString.length > 0 && tcfData.purposeOneTreatment === true) { |
There was a problem hiding this comment.
I don't understand why purposeOneTreatment or purpose 1 in general matters here.
There was a problem hiding this comment.
This was the advice from Xandr legal counsel. We might in the future add a flag to get around it, but for now it's an edge case in the flowchart.
There was a problem hiding this comment.
Trying to understand the lawyer's rational - Purpose 1 has to do with device access, right? And this conditional says that we're passing the consent string (if it exists) through to the bidders while the cmp ui is still being shown to the user, as long as they've given device access consent. What does passing consent on to the bidders have to do with device access?
Taking a shot at an explanation - If we know that the user has already given some positive consent (good) pass the string along. If not (not as good), give them the opportunity to change it.
There was a problem hiding this comment.
It's saying that we can move on with an older or incomplete version of consent without waiting for the useractioncomplete event as long as the string contains indication that publisher declared the ability to "read the device". It's unclear to me that this is an obvious fit for purposeOneTreatment, but P1T's actual meaning is murky and this doesn't seem like it should hurt anything.
If P1T isn't utilized, the PBJS will just wait for the user action to complete.
|
This pull request introduces 1 alert when merging 9e290df into 703b898 - view on LGTM.com new alerts:
|
* initial support for TCF2 * update wording in err message * update logic and comment around safeframe workflow * fix typo
* initial support for TCF2 * update wording in err message * update logic and comment around safeframe workflow * fix typo
* initial support for TCF2 * update wording in err message * update logic and comment around safeframe workflow * fix typo
Type of change
Description of change
Implements the feature described in #4801
Key things to note:
NOTE This does slightly change the logic used for the v1 checks, which only checked the current window then the top window when finding the CMP API. I think this should be fine.
removeEventListenersreferences in order to keep the listeners open and ready to respond. This also includes removing thedelete cmpCallbacks[i.callId];code we had for the iframe route (so we can act properly when a follow-up event is triggered from the originalcallId).userId/index.jsto handle looking at the updated version of thevendorDataobject for the TCF2 spec.As a follow-up to the last note, the are 8 bid adapters (currently) who read the
gdprConsent.vendorDatafield to either do some logic or pass along some of the values in their request. These bidders are as followed:Ideally, these adapters should be updated to read the new
gdprConsent.apiVersionfield so they can look at the updated locations/field names for thevendorDatathey need to know. I (hopefully) tagged all the main contributors so they are aware.