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

Stored Request IDs unique to Account #1024

Open
bretg opened this issue Sep 6, 2019 · 2 comments
Open

Stored Request IDs unique to Account #1024

bretg opened this issue Sep 6, 2019 · 2 comments
Labels

Comments

@bretg
Copy link
Contributor

bretg commented Sep 6, 2019

Problem

We're running into the problem of installed mobile apps that use stored-request-ids with names that could conceivably be used by other publishers. i.e. there's an unchangeable installed base of Stored Request IDs (SRIDs) that have a higher chance of collision than we'd like.

Feature

To avoid SRID collisions we propose:

  1. the request's account ID is considered ext.prebid.parentAccount, site.publisher.id, or app.publisher.id in that order.
  2. add a column to the stored_request query response for "accountId".
  3. query for the SRID as usual
  4. if more than one row comes back in the DB or DB-cache response, use the "accountId" field to choose which one to use
  5. if only one row matches, but the account ID doesn't match, reject as if there hadn't been an SRID match
  6. if the "accountId" field is blank on the query results then the PBS host company isn't using the account feature, so as long as there's only one row matching the SRID, go ahead and use it.
  7. if there are multiple SRIDs and no account ID on the incoming request or on the DB response, report an appropriate error instead of choosing randomly.
@bretg bretg added the Intent to implement An issue describing a plan for a major feature. These are intended for community feedback label Sep 6, 2019
@bretg
Copy link
Contributor Author

bretg commented Sep 8, 2019

Discussed and approved in PBS PMC

@bretg
Copy link
Contributor Author

bretg commented Nov 12, 2020

Released with PBS-Java 1.47

@bretg bretg added the PBS-Go label Nov 12, 2020
@SyntaxNode SyntaxNode added Ready For Dev Feature specification is ready to be developed. and removed Intent to implement An issue describing a plan for a major feature. These are intended for community feedback labels Sep 7, 2022
@bretg bretg removed the projectboard label Sep 8, 2022
@bretg bretg moved this from Triage to Ready for Dev in Prebid Server Prioritization Dec 2, 2022
@bretg bretg removed the Ready For Dev Feature specification is ready to be developed. label Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Ready for Dev
Development

No branches or pull requests

2 participants