/cookie_sync Endpoint Rewrite#1879
Conversation
Bidder user sync configs
|
|
||
| errs := validateSyncers(t, bidderInfos) | ||
| assert.Empty(t, errs, "syncer errors") | ||
| } |
There was a problem hiding this comment.
I improved the unit tests to use the same exact loading mechanism the app uses at startup to ensure no issues / the same validation is performed.
|
|
||
| // a syncer may provide just a Supports field to provide hints to the host. we should only try to create a syncer | ||
| // if there is at least one non-Supports value populated. | ||
| return cfg.Syncer.Key != "" || cfg.Syncer.Default != "" || cfg.Syncer.IFrame != nil || cfg.Syncer.Redirect != nil || cfg.Syncer.SupportCORS != nil |
There was a problem hiding this comment.
This is a bit hacky. Perhaps it would be better to use different data structures for yaml vs config overrides... but I think this works.
| givenConfig: hostConfig, | ||
| givenBidderInfos: map[string]config.BidderInfo{"bidder1": infoKeyAEmpty, "bidder2": infoKeyAError}, | ||
| expectedErrors: []string{ | ||
| "cannot create syncer for bidder bidder2 with key a: default is set to redirect but no redirect endpoint is configured", |
There was a problem hiding this comment.
Just to confirm, bidder1 does not result in an error here even though it is missing endpoints and a default because it shares the same key as bidder2 and bidder2 is supposed to define the endpoints for that key since it specifies a default right?
There was a problem hiding this comment.
Correct. Exactly. I wrote it to cover the case where two bidders share the same key but the primary configuration (bidder2 here) is invalid.
| _, err = syncer.GetSync([]usersync.SyncType{usersync.SyncTypeIFrame, usersync.SyncTypeRedirect}, privacyPolicies) | ||
| if err != nil { | ||
| return fmt.Errorf("syncer has invalid macro: %s", err) | ||
| for _, v := range bidderInfo.Syncer.Supports { |
There was a problem hiding this comment.
You're leaning on the app validation performed in BuildSyncers in your tests but then we have this additional test only check here that makes sure we don't have an invalid supports type in the bidder info file. Shouldn't we be checking for invalid support types within our app validation too?
There was a problem hiding this comment.
Good point. It was my intention to emit a warning for supported user syncs which aren't configured. I've added that feature with the supports validation.
| assert.Equal(t, test.expectedBidderInfos, test.givenBidderInfos, test.description+":result") | ||
| } else { | ||
| assert.EqualError(t, resultErr, test.expectedError, test.description+":err") | ||
| } |
There was a problem hiding this comment.
I realize that I'm not asserting the glog warnings. That's because we don't have a good way to intercept the log writes for tests. I'd like to see that fixed, but that would be too much work for this PR. I manually verified for now.
| switch endpointLower { | ||
| case "iframe": | ||
| if info.Syncer.IFrame == nil { | ||
| glog.Warningf("bidder %s supports iframe user sync, but doesn't have a default and must be configured by the host", name) |
There was a problem hiding this comment.
Just wanted to confirm that you don't feel a need to test for the warning. You do test for the error below.
There was a problem hiding this comment.
I added a comment about that lack of coverage a little while ago.
I'd really like to test the warning, but we don't have an interface for logging and intercepting glog through output redirection isn't a good option. I think adding that logging interface is too much to do here, so I leave it for a future project. There are many other glog warnings we equally have no automated test coverage on. I ran through the test cases manually to ensure the proper glog output.
I also thought of using warnings and errors as returns from the method instead using our existing errortypes functionality, but then I need to filter them out in the router and it seemed to be getting messy IMHO.
Happy to add the assertions if you have an idea for how to reasonable approach it.
|
Docs PR: prebid/prebid.github.io#3220 |
… prebid-master * 'master' of https://github.com/prebid/prebid-server: Update Viper (prebid#1969) /cookie_sync Endpoint Rewrite (prebid#1879) New Adapter: IQZone (prebid#1964) Remove old race conidtion tests (prebid#1958) Remove time.Now() as the first parameter of NewRates() (prebid#1953) # Conflicts: # config/config.go # usersync/usersyncers/syncer_test.go
I've rewritten the majority of the /cookie_sync endpoint and user syncer architecture to implement #924, #1477, #1554, and to further progress #1429 as the config system now includes user syncing settings.
Todo
Configuration Changes
Technical details will be included in a separate PR to https://github.com/prebid/prebid.github.io before this is merged.
static/bidder-infofrom being hardcoded in theconfig.goand adapterusersync.gofiles. Hosts can now override all user syncing options via eitherpbs.yamlor environment variables.usersync_urloverrides are temporarily supported for backwards compatibility, but please update your configs as soon as possible after release.adnxshardcoded handling for AppNexus.Example Current Config: Buried In
config/config.goExample New Config: In
static/bidder-info/appnexus.yamlAPI Changes
/cookie_syncendpoint now defaults to all bidders if the bidders field in the request is missing, null, or empty. This matches behavior in PBS-Java. We discussed and couldn't find a use case for handling each of these conditions separately. Currently, a missing bidders parameter results in an error response, a null parameter results in using all bidders, and an empty parameter results in no user syncing./cookie_sync endpointwill now accept filters in the request defining which user sync types (iframe, redirect) are permitted. The format is fully compatible with Prebid.js and PBS-Java.SSCookiesidecar cookie is no longer required and is removed with this PR./setuidendpoint will now properly respond with an empty image for redirects and an empty html response for iframes.Metric Changes
Influx
Metrics have be reorganized around endpoint names and syncer keys.
cookie_sync_requests.*are directly related to the/cookie_syncendpoint,set_uid_requests.*are directly related to the/setuidendpoint, andsyncer.*are related to each syncer. Specifically,usersync.opt_outsandusersync.bad_requestsare removed and replaced withcookie_sync_requests.[status]where status isok,bad_request,opt_out, andgdpr_blocked_host_cookie.usersync.unknown.setsandusersync.unknown.gdpr_preventare removed and replaced withset_uid_requests.key_unknown.cookie_syncs[bidder].genandcookie_sync.[bidder].gdpr_preventare removed and replaced withsyncer.[key].request.[status]where the syncer key may be shared among multiple bidders and status isok,privacy_blocked,already_synced,type_not_supported.usersync.[bidder].setsandusersync.[bidder].gdpr_preventare removed and replaced withsyncer.[key].set.[status]where the syncer key may be shared among multiple bidders and status isokandprivacy_blocked.setuid_requests.[status]is new where status isok,opt_out,gdpr_blocked_host_cookie,key_unknown, andtype_not_supported.Prometheus
Metrics have be reorganized around endpoint names and syncer keys.
cookie_sync_requestsis directly related to the/cookie_sync endpoint,set_uid_requestsis directly related to the/setuidendpoint,syncer_requestsandsyncer_setsare related to each syncer. Specifically,cookie_sync_requestnow has a status label with valuesok,bad_request,opt_out, andgdpr_blocked_host_cookie. Existing PromQL queries will still accurately report the total number of requests to the endpoint.setuid_requestsis new and has a status label with valuesok,opt_out,gdpr_blocked_host_cookie,key_unknown, andtype_not_supported.adapter_cookie_synchas been removed and replaced withsyncer_requestswhich has a syncer key label and status label with the valuesok,privacy_blocked,already_synced,type_not_supported. These syncer metrics are only counted when the syncer has been selected as a user sync candidate.adapter_user_synchas been removed and replaced withsyncer_setswhich has a syncer key label and status label with the valuesokandprivacy_blocked.Future Plans
I'm working on account settings for the /cookie_sync endpoint, but this PR is already huge so that will be separate later on.