Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consent Management module - Impossible to get the callbacks used by CMP in a Postbid setup #3356

Closed
Deimos01 opened this issue Dec 5, 2018 · 6 comments

Comments

@Deimos01
Copy link

Deimos01 commented Dec 5, 2018

Type of issue

Bug

Description

When Prebid is embeded in an iframe (DFP w/o Secure frame, adservers ...), the Consent Management module seems to have difficulties to get the callbacks of the CMP (Quantcast). The module timeout is always reached, even for a non-European IP.
So I guess the module detects the CMP but can't access to the callback.

Steps to reproduce

In a postbid setup, try to put your CMP on the webpage then call your Prebid file through an adserver (DFP, Smartadserver ...) with the Consent Management module enabled.

Test page

test page

Expected results

The Consent Management module should detect the callback of the CMP, even through the iframes.

Actual results

The Consent Management module can't access to the callback, the module timeout is reached.
capture d ecran 2018-12-05 a 16 33 33

Platform details

Prebid 1.34 - all platforms - all geos

Other information

I think the issue is related to this PR : 2626

@mkendall07
Copy link
Member

@jsnellbaker can you take a look at this please?

@jsnellbaker
Copy link
Collaborator

jsnellbaker commented Dec 13, 2018

@Deimos01 I've looked through the setup and tried to debug the CMP calls as they go back and forth between the page's CMP code and the smart.js file's CMP code.

Below is a short recap of what I observed:

  • the consentManagement module's code starts off working as expected. It properly detects the window.__cmp on the page and executes the calls for getConsentData and getVendorConstents.
  • These calls go to the smart.js file, get processed, and then go to the page-level code that puts together the response.
  • That page-level code seems to trigger the postMessage request that's meant to go back to the smart.js file's listener callback function, but that seems to be the point where the workflow breaks down. The callback function in the smart.js file doesn't get called for some reason.

This is strange because our Prebid CMP calls aren't the only ones making CMP calls on the page. When I setup breakpoints in the page-level CMP code and in the smart.js CMP code*, I saw the smart.js receive the responses and process them (ie load the callback function that was included in the CMP request). These requests happened and got processed before the Prebid code started to load.

As to any theories on the cause of the issue, I did observe a certain sequence of events during those first round of CMP calls. There appears to be a window.__cmp(getConsentData,...) request embedded in the smart.js file. In the callback function for this request, it loaded another function called removeEvent. This removeEvent function appears to remove eventListeners objects that were presumably set earlier in the code. After loading this function, it further processes the consentData by setting a cookie (named sas_euconsent).

This is just a guess, but maybe in removing the eventListener, it prevented the subsequent CMP calls from being picked up and handled when the responses were sent from the page-level CMP code. This may not be an intentional thing; there may be a race-condition of sorts due to the parallel/asynchronous calls from the different sources. I think this is a possibility as during one page load, I saw the Prebid CMP calls go first and they were properly handled by the CMP code (ie our callback functions were executed and the auction loaded without the CMP timeout error).

I know this isn't a smoking gun and only a theory, but could you check with the providers of the CMP to see if they have any thoughts about the above?

  • note - this is minified code, so there are some limitations in debugging/reading the code.

@Deimos01
Copy link
Author

Thank you very much @jsnellbaker to take the time to investigate.

I think your theory is entirely true. I did a revealing test related to the smart.js theory.
Here a new test page. The setup is exactly the same, I've just delayed the load of smart.js of 2 seconds and the Consent Module Management seems to work well.
For your information, smart.js is the JS library loaded by Smart Adserver when you use them as an adserver instead of DFP.

Please do not close this issue, I'm contacting the Smart team to take a look.
Probably others publishers who are using Smart Adserver as an adserver have the same problem.

@stale
Copy link

stale bot commented Dec 28, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Dec 28, 2018
@stale stale bot closed this as completed Jan 4, 2019
@Deimos01
Copy link
Author

Smart Adserver has just released a fix in their JS library to avoid that conflict. The issue is now solved.

Thank you very much for your time.

@mkendall07
Copy link
Member

thanks for the follow-up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants