New Adapter: TRUSTX (remove Grid alias)#4614
Conversation
Code coverage summaryNote:
trustxRefer here for heat map coverage report |
|
Please rebase this PR with the latest changes as that is causing the server to not be up due to a bug which has been fixed |
6e452fe to
2b6b83f
Compare
Code coverage summaryNote:
trustxRefer here for heat map coverage report |
|
Hi @karwaankit32, rebased! Is there anything else I can do to expedite merging this PR? |
Thanks. I am in the process of reviewing the PR today and will post feedback by EOD. Thanks! |
| } | ||
|
|
||
| var validParams = []string{ | ||
| `{}`, |
There was a problem hiding this comment.
Question: is a default Uid being 0 acceptable here? Is there a reason why we are not making Uid required?
There was a problem hiding this comment.
Hi, 0 is acceptable, as publishers can also pass the value in other fields (e.g. imp.tagid)
| `{"uid": 1234}`, | ||
| `{"uid": 1234, "keywords":{"site": {}, "user": {}}}`, | ||
| } | ||
| var invalidParams = []string{ |
There was a problem hiding this comment.
Can we add other test cases where we also check data types of Uid and Keywords?
Ex: passing a "string" Uid and similarly for Keywords?
There was a problem hiding this comment.
Added 2 test cases.
adapters/trustx/trustx.go
Outdated
| func setImpExtData(imp *openrtb2.Imp) { | ||
| var ext impExt | ||
| if err := jsonutil.Unmarshal(imp.Ext, &ext); err != nil { | ||
| return |
There was a problem hiding this comment.
do we want to log these errors?
There was a problem hiding this comment.
I don't think so, as the data read from the imp ext (adslot) is optional to us, and the request is valid without it.
There was a problem hiding this comment.
Makes sense but i'd recommend adding a test case for this
There was a problem hiding this comment.
Added a test case for this!
| return nil | ||
| } | ||
| var bidMeta *openrtb_ext.ExtBidPrebidMeta | ||
| if be.Bidder.TrustX.NetworkName != "" { |
There was a problem hiding this comment.
Can there be a case where TrustX is empty? Won't this logic break in such cases?
There was a problem hiding this comment.
Yes, there can be a case where we don't return the network name, but TrustX isn't a pointer so nothing will break, bid meta will just be nil.
Code coverage summaryNote:
trustxRefer here for heat map coverage report |
Code coverage summaryNote:
trustxRefer here for heat map coverage report |
| redirect: | ||
| url: "https://x.bidswitch.net/check_uuid/{{.RedirectURL}}?gdpr={{.GDPR}}&gdpr_consent={{.GDPRConsent}}&us_privacy={{.USPrivacy}}" | ||
| userMacro: "${BSW_UUID}" | ||
|
No newline at end of file |
||
| url: "https://sync.trustx.org/usync-pbs?us_privacy={{.USPrivacy}}&gpp={{.GPP}}&gpp_sid={{.GPPSID}}&redirect={{.RedirectURL}}" | ||
| userMacro: "$UID" |
| iframe: | ||
| url: "https://static.cdn.trustx.org/x/user_sync.html?source=pbs&us_privacy={{.USPrivacy}}&gpp={{.GPP}}&gpp_sid={{.GPPSID}}&redirect={{.RedirectURL}}" | ||
| userMacro: "$UID" |
There was a problem hiding this comment.
Iframe does not appear to be working. I see a 200 response from this endpoint with an html body which is triggering a request to https://sync.trustx.org/usync and that is redirecting to the PBS setuid endpoint assuming https but in this case it is http.
Is the redirect necessary? I believe I have seen other adapters embed the PBS host URL in the html response firing a request to the setuid endpoint directly from the client.
There was a problem hiding this comment.
Hi, the failure is caused by browser mixed-content restrictions: an HTTPS iframe cannot initiate requests to an HTTP PBS setuid endpoint.
This would fail even without the redirect hop (calling the endpoint directly from the client).
For iframe sync to work reliably, the PBS endpoint must be served over HTTPS.
This is not adapter-specific behavior, but a native browser security restriction.
Reference: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Mixed_content
There was a problem hiding this comment.
Hi @bsardo , could you please take a look at my comment above?
bsardo
left a comment
There was a problem hiding this comment.
Looks good, just a couple of comments.
| @@ -1,9 +1,19 @@ | |||
| aliasOf: grid | |||
| endpoint: "https://ads.trustx.org/pbs" | |||
There was a problem hiding this comment.
Verified endpoint is reachable
curl -i --location --request POST https://ads.trustx.org/pbs
HTTP/2 204
access-control-allow-credentials: true
access-control-allow-origin: *
vary: Origin
date: Fri, 30 Jan 2026 15:11:03 GMT
| maintainer: | ||
| email: "grid-tech@themediagrid.com" | ||
| gvlVendorID: 686 | ||
| email: "prebid@trustx.org" |
There was a problem hiding this comment.
We've sent an email to this address. Please respond with a message of 'received' to confirm that it is reachable.
| extJSON, err := jsonutil.Marshal(ext) | ||
| if err == nil { | ||
| imp.Ext = extJSON | ||
| } |
There was a problem hiding this comment.
We are ok with swallowing the unmarshalling error above in this function but please do not swallow marshaling errors. We've seen instances in production where shared memory corruption results in a marshalling error causing an adapter panic that tips us off that there is a real problem.
There was a problem hiding this comment.
Changed marshalling error handling
There was a problem hiding this comment.
Is this test needed? It looks like your other tests already cover what it is covering.
Code coverage summaryNote:
trustxRefer here for heat map coverage report |
Code coverage summaryNote:
trustxRefer here for heat map coverage report |
bsardo
left a comment
There was a problem hiding this comment.
Looks good. Once I receive a response to the email I sent to prebid@trustx.org I will approve.

Docs PR: prebid/prebid.github.io#6355