On my first call to the authorize endpoint where I’m redirected to the login page the return message doesn’t have the origin/referrer so this message is being blocked (as we have origin verifying). I’m required to do a subsequent call, that doesn’t go to the login page, to get a return message with the auth code, origin and referrer.
Is this intended functionality to not return an origin/referrer from the login screen? Is there potentially something I’m missing?
I’m using google chrome, it only seems to be an issue when I’m redirected to the login page; if I’ve previously logged in then it skips the login page and works fine
As I previously stated, it is the browser that will insert the origin and referrer header into the request (they are not included in the response). Origin is intended for cross-origin traffic and may not be included for GET requests (other rules apply). Similarly the referrer indicates the original source and from testing is included in calls. If they are being excluded this is likely a browser config (privacy setting) or overly aggressive firewall rules blocking the request.
@sgroom I’ve checked the requests and the referer header is always set using chrome (and other browsers) when making http requests to the CIS2 Auth service and when redirecting back to the RP with the auth code.
The Origin header is only included as per the HTTP specs when a cross-origin request is being made. It will not be added to a page request even when triggered by a redirect or for resources loaded from the same domain.
Please provide further details (URLs) where you expect these headers to be added and they are not present