Skip to content

Conversation

@trustXops
Copy link

@trustXops trustXops commented Nov 26, 2025

@github-actions
Copy link

Code coverage summary

Note:

  • Prebid team doesn't anticipate tests covering code paths that might result in marshal and unmarshal errors
  • Coverage summary encompasses all commits leading up to the latest one, 6e452fe

trustx

Refer here for heat map coverage report

github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:50:	Builder		100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:57:	MakeRequests	81.8%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:82:	MakeBids	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:116:	setImpExtData	87.5%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:130:	getHeaders	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:162:	getTypedBid	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:193:	getBidMeta	100.0%
total:									(statements)	96.2%

@karwaankit32
Copy link

karwaankit32 commented Jan 9, 2026

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

@trustXops trustXops force-pushed the trustx-bidder-adapter branch from 6e452fe to 2b6b83f Compare January 9, 2026 10:15
@github-actions
Copy link

github-actions bot commented Jan 9, 2026

Code coverage summary

Note:

  • Prebid team doesn't anticipate tests covering code paths that might result in marshal and unmarshal errors
  • Coverage summary encompasses all commits leading up to the latest one, 2b6b83f

trustx

Refer here for heat map coverage report

github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:50:	Builder		100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:57:	MakeRequests	81.8%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:82:	MakeBids	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:116:	setImpExtData	87.5%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:130:	getHeaders	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:162:	getTypedBid	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:193:	getBidMeta	100.0%
total:									(statements)	96.2%

@trustXops
Copy link
Author

Hi @karwaankit32, rebased! Is there anything else I can do to expedite merging this PR?

@karwaankit32
Copy link

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{
`{}`,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: is a default Uid being 0 acceptable here? Is there a reason why we are not making Uid required?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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{

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added 2 test cases.

func setImpExtData(imp *openrtb2.Imp) {
var ext impExt
if err := jsonutil.Unmarshal(imp.Ext, &ext); err != nil {
return

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to log these errors?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense but i'd recommend adding a test case for this

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a test case for this!

return nil
}
var bidMeta *openrtb_ext.ExtBidPrebidMeta
if be.Bidder.TrustX.NetworkName != "" {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can there be a case where TrustX is empty? Won't this logic break in such cases?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@github-actions
Copy link

github-actions bot commented Jan 9, 2026

Code coverage summary

Note:

  • Prebid team doesn't anticipate tests covering code paths that might result in marshal and unmarshal errors
  • Coverage summary encompasses all commits leading up to the latest one, 058ffe5

trustx

Refer here for heat map coverage report

github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:50:	Builder		100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:57:	MakeRequests	81.8%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:82:	MakeBids	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:116:	setImpExtData	87.5%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:130:	getHeaders	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:162:	getTypedBid	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:193:	getBidMeta	100.0%
total:									(statements)	96.2%

@github-actions
Copy link

github-actions bot commented Jan 9, 2026

Code coverage summary

Note:

  • Prebid team doesn't anticipate tests covering code paths that might result in marshal and unmarshal errors
  • Coverage summary encompasses all commits leading up to the latest one, 5cc01b6

trustx

Refer here for heat map coverage report

github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:50:	Builder		100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:57:	MakeRequests	81.8%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:82:	MakeBids	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:116:	setImpExtData	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:130:	getHeaders	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:162:	getTypedBid	100.0%
github.com/prebid/prebid-server/v3/adapters/trustx/trustx.go:193:	getBidMeta	100.0%
total:									(statements)	97.5%

Comment on lines 16 to 19
redirect:
url: "https://x.bidswitch.net/check_uuid/{{.RedirectURL}}?gdpr={{.GDPR}}&gdpr_consent={{.GDPRConsent}}&us_privacy={{.USPrivacy}}"
userMacro: "${BSW_UUID}"

url: "https://sync.trustx.org/usync-pbs?us_privacy={{.USPrivacy}}&gpp={{.GPP}}&gpp_sid={{.GPPSID}}&redirect={{.RedirectURL}}"
userMacro: "$UID"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified redirect works. The endpoint successfully redirects to the PBS setuid endpoint with the trustx uid which is then set in the PBS cookie by the setuid endpoint.

Screenshot 2026-01-09 at 2 26 52 PM

Comment on lines +14 to +16
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"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Screenshot 2026-01-09 at 2 35 39 PM

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants