During authentication, the library returns this error:
The response was received at https://domain.com/portal/connect/azure/connect/azure/check instead of https://domain.com/portal/connect/azure/check
Environment Context:
In one of our environments, a "portal" prefix is added to the URL path. This prefix is stripped by a reverse proxy, and the request arrives without this prefix on the application server.
Problem:
This causes an issue during the "destination" validation. In the buildWithBaseURLPath() function, the requestUri parameter arrives without the prefix, but the $baseURLPath variable still contains this prefix. The result is that the baseUrlPath construction fails and some path elements get duplicated.
To bypass the problem, I implemented a hack by modifying the REQUEST_URI variable before processing:
if (!empty($_SERVER['HTTP_X_FORWARDED_PREFIX'])) {
$_SERVER['REQUEST_URI'] = sprintf(
'%s%s',
$_SERVER['HTTP_X_FORWARDED_PREFIX'],
$request->getRequestUri(),
);
}
$oneLoginAuth->processResponse(); Is there a better/cleaner way to handle this issue without modifying the global $_SERVER['REQUEST_URI'] variable ?
It would be great if the library could handle reverse proxy scenarios, perhaps by automatically detecting and handling X-Forwarded-* headers.
During authentication, the library returns this error:
The response was received at https://domain.com/portal/connect/azure/connect/azure/check instead of https://domain.com/portal/connect/azure/checkEnvironment Context:
In one of our environments, a "portal" prefix is added to the URL path. This prefix is stripped by a reverse proxy, and the request arrives without this prefix on the application server.
Problem:
This causes an issue during the "destination" validation. In the
buildWithBaseURLPath()function, therequestUriparameter arrives without the prefix, but the$baseURLPathvariable still contains this prefix. The result is that thebaseUrlPathconstruction fails and some path elements get duplicated.To bypass the problem, I implemented a hack by modifying the
REQUEST_URIvariable before processing:Is there a better/cleaner way to handle this issue without modifying the global
$_SERVER['REQUEST_URI']variable ?It would be great if the library could handle reverse proxy scenarios, perhaps by automatically detecting and handling
X-Forwarded-*headers.