IX Bid Adapter: POST Support

[lksharma]

Type of change

• Bugfix

• Feature

• New bidder adapter

• Code style update (formatting, local variables)

• Refactoring (no functional changes, no api changes)

• Build related changes

• CI related changes

• Does this change affect user-facing APIs or examples documented on http://prebid.org?

• Other

Description of change

This release supports the switch from GET to POST requests via features

Be sure to test the integration with your adserver using the [Hello World](/integrationExamples/gpt/hello_world.html) sample page. -->


## Other information
@lksharma: [email protected]

[patmmccann]

Why is it useful to read these values from local storage instead of relying on configuration

[lksharma]

enabling post is dependent on our server response for the moment. We are reading from an internal config and local storage when available. The advantage of reading from local storage is we can capture requests on page load rather than waiting for a response.

[lksharma]

@patmmccann let me know if you have any additional questions.

[patmmccann]

setting ix_features: {"expiry":,"features":{"pbjs_enable_post":{"activated":true}}}

in local storage and giving a bidder an override to access local storage to enable post method seems to be a bizarre workflow for a publisher and also seems undocumented. I feel like I must be missing something here. Why couldn't the publisher opt into IX post mode via a more standard method?

We're attempting to minimize bidder access to local storage and make it a rare event, not standard practice.

[lksharma]

@patmmccann

We won't be relying on local storage to activate POST. Local storage access will allow us to generate POST requests on page load but this is not a dependency and is more of a nice to have.

If reading from local storage is not allowed then POST will be limited to ad refreshes on the page (since pbjs_enable_post flag is dependent on our server response). In a future PR, we will be moving completely to POST. The intention here is to roll out POST within our adapter gradually.

[patmmccann]

This is an unsatisfying reason; we'll discuss in committee. I recommend you plan on this not being approved.

[lksharma]

Is the use of local storage the concern here? If so, would refactoring to remove the usage of local storage help address those concerns?

[jsnellbaker]

Hi @lksharma

While I think the overall code looks fine (baring Patrick's feedback about the localStorage question), I was hoping to test these changes to verify the POST request completes successfully.

Do you have some sample params I can use that should invoke this state? I was trying with some of the values in the md file and hardcoding some values in localStorage, but I'd rather test with the expected natural workflow, if possible. Please let me know when you have the chance.

Thanks.

[lksharma]

@jsnellbaker,

Thanks for looking into this. You can test the code flow with the following local storage value:

ix_features: {"expiry":<TIMESTAMP>,"features":{"pbjs_enable_post":{"activated":true}}}

TIMESTAMP = new Date().setHours(new Date().getHours() + 1)
^ sets the expiry value to an hour.

Let me know if you need anything else.

[jsnellbaker]

Thanks for the feedback @lksharma

With that in place in the localStorage (and the bidderSettings storageAllowed setting enabled), the logic presented here appears to be working fine.

Will wait on merging for Patrick's feedback.

[patmmccann]

Generally, this use of local storage is not a rules violation, but it feels bizarre and difficult to explain to publishers, who will have to grant you access to local storage one by one. I recommend retooling to avoid these conversations and to give publishers a simpler way to enable post mode. Since Prebid 7 was released, your adapter will not have access to local storage by default.

[patmmccann]

spoke with Luke at IX, merging

The use of local storage is not critical to the server side control of get vs post, but enhances it. The feature will still work for publishers who don't make an exception.