setuid's not picking up an account id

[spormeon]

I think I have found a "knock on" problem to #4411 , account endpoints now work but all the "host" setuids are 400'ing out with a "account must be valid if provided, please reach out to the prebid server host", deafult accounts are set to false

I see this setting in config.go: v.SetDefault("user_sync.redirect_url", "{{.ExternalURL}}/setuid?bidder={{.SyncerKey}}&gdpr={{.GDPR}}&gdpr_consent={{.GDPRConsent}}&gpp={{.GPP}}&gpp_sid={{.GPPSID}}&f={{.SyncType}}&uid={{.UserMacro}}")

if I "hardcode" an account in the setting, it works and we start getting 200's: {{.ExternalURL}}/setuid?account=XXXXXX&bidder={{.SyncerKey}}&gdpr={{.GDPR}}&gdpr_consent={{.GDPRConsent}}&gpp={{.GPP}}&gpp_sid={{.GPPSID}}&f={{.SyncType}}&uid={{.UserMacro}}

1. I have no clue if there is a "macro" for the account id?
2. do/ should the acountid even be included on setuid's in the "greater scheme of things"
3. Am i just missing some "setting" that sorts it all out anyway, no clue, cant find any docs on it anywhere

[SyntaxNode]

What is the purpose of including an account id in the setuid request?

[spormeon]

@SyntaxNode so that the setuid's calls dont 400 error out, like they currently do, they only 200 when the account id is there. In the bigger scheme of things , sucah as if its "better" to have an account id, or not for "performance", i dont have a clue on that front

200's with account id:

400's without account id

with these accounts settings, so every account must validate, not have a "deafult" fill in the gaps:

[spormeon]

Is it maybe something to do with the account stuff here?

setuid.go

[spormeon]

I also have this set in the account json, so I dont think its an account miss config, unless I'm missing some other account variable: "cookie_sync": { "enabled": true, "max_limit": 10, "default_limit": 5, "default_coop_sync": true },

full account json: { "id": "XXXXXXX", "ccpa": { "enabled": true, "channel_enabled": { "amp": true, "app": false, "web": true, "video": true }, "integration_enabled": { "amp": null, "app": null, "web": null, "video": null } }, "gdpr": { "enabled": true, "purpose1": { "enforce_algo": "basic", "enforce_purpose": true, "enforce_vendors": true, "vendor_exceptions": [ "bidderA" ] }, "purpose2": { "enforce_algo": "basic", "enforce_purpose": false, "enforce_vendors": false, "vendor_exceptions": [] }, "purpose3": { "enforce_algo": "", "enforce_purpose": null, "enforce_vendors": null, "vendor_exceptions": [] }, "purpose4": { "enforce_algo": "", "enforce_purpose": null, "enforce_vendors": null, "vendor_exceptions": [] }, "purpose5": { "enforce_algo": "", "enforce_purpose": null, "enforce_vendors": null, "vendor_exceptions": [] }, "purpose6": { "enforce_algo": "", "enforce_purpose": null, "enforce_vendors": null, "vendor_exceptions": [] }, "purpose7": { "enforce_algo": "", "enforce_purpose": null, "enforce_vendors": null, "vendor_exceptions": [] }, "purpose8": { "enforce_algo": "", "enforce_purpose": null, "enforce_vendors": null, "vendor_exceptions": [] }, "purpose9": { "enforce_algo": "", "enforce_purpose": null, "enforce_vendors": null, "vendor_exceptions": [] }, "purpose10": { "enforce_algo": "", "enforce_purpose": null, "enforce_vendors": null, "vendor_exceptions": [] }, "channel_enabled": { "amp": true, "app": false, "web": true, "video": true }, "special_feature1": { "enforce": true, "vendor_exceptions": [ "bidderA" ] }, "integration_enabled": { "amp": null, "app": null, "web": null, "video": null }, "purpose_one_treatment": { "enabled": true, "access_allowed": true }, "basic_enforcement_vendors": [ "vendorA", "vendorB" ] }, "hooks": { "modules": { "vendorA": { "moduleA": { "key1": "value1" } } }, "execution_plan": {} }, "events": { "enabled": false, "default_url": "", "vast_events": [] }, "privacy": { "ipv4": { "anon_keep_bits": 24 }, "ipv6": { "anon_keep_bits": 56 }, "allowactivities": { "ACCESS_DEVICE": { "rules": [], "default": true }, "TRANSMIT_EIDS": { "rules": [], "default": true } } }, "disabled": false, "cache_ttl": { "audio": 300, "video": 600, "banner": 300, "native": 300 }, "cookie_sync": { "enabled": true, "max_limit": 10, "default_limit": 5, "default_coop_sync": true }, "debug_allow": true, "validations": { "max_creative_width": 300, "max_creative_height": 300, "banner_creative_max_size": "skip" }, "bid_rounding": "up", "price_floors": { "enabled": true, "max_rules": 100, "max_schema_dims": 10, "use_dynamic_data": false, "enforce_deal_floors": false, "enforce_floors_rate": 100, "adjust_for_bid_adjustment": true }, "bidadjustments": { "bidderA": 1.1, "bidderB": 0.9 }, "events_enabled": null, "default_bid_limit": 5, "default_integration": "web", "alternatebiddercodes": null, "truncate_target_attr": 30 }

[SyntaxNode]

Thank you for the further explanation. I understand the issue.

I have no clue if there is a "macro" for the account id?

There is not. Might be a good idea to add it as a macro. The account can be passed to the getuids endpoint, but that's uncommon.

do/ should the acountid even be included on setuid's in the "greater scheme of things"

Yes, it should be included. This is useful for privacy control, which is why I asked my earlier question about how/why you are using the account in the user sync endpoints.

Am i just missing some "setting" that sorts it all out anyway, no clue, cant find any docs on it anywhere

Unlikely.

[spormeon]

@SyntaxNode so there is some code not "behaving" right somewhere? not sending in the account=XXXXX ?

[SyntaxNode]

so there is some code not "behaving" right somewhere?

PBS is behaving as it should, but you've discovered this not ideal. You may be the first to run PBS in the account required mode.

[SyntaxNode]

This seems to me as an unintended side affect of requiring an account. That clearly makes sense for an auction, which is very resource intensive, and less sense for a user sync operation.

I support either removing this requirement from the user sync endpoints, or allowing hosts to customize the behavior with a new config option. I'll discuss this with the PMC.

[spormeon]

ok, got you. Something potentially this this then ish?

PBS_ACCOUNTS_SETUID: true/ false

true, sets the macro {{accounts}} false, setuid url fires without requiring account and stops throwing "account must be valid if provided, please reach out to the prebid server host"

[bsardo]

Discussed at the PMC. We will add a configuration option that requires account id on the cookie sync endpoints and we will use that config option to determine whether an account ID is required on those endpoints. The config option will default to false. cookie_sync.enforce_valid_account and setuid.enforce_valid_account.

[spormeon]

@bsardo ok, how does that effect @SyntaxNode comment about it potentially being needed? "do/ should the acountid even be included on setuid's in the "greater scheme of things"

Yes, it should be included. This is useful for privacy control, which is why I asked my earlier question about how/why you are using the account in the user sync endpoints."

[spormeon]

@bsardo @SyntaxNode Any idea on a time frame guys on this, the hack/ work around of a "dummy" account hardcoded in doesn't seem to be the right way to go, which is what seems to work at the moment