I'm having the same issue.

A solution would be to authorize customizing zabbix front end baseurl setting

raw fix : edit the index_sso.php file

set the baseurl variable to your fqdn

add the following variable in the $settings array : $settings['baseurl'] = $baseurl;

Thank you for fast fix i will try it.

On sites we are using docker deployment, is there any way to set it via environment?

I'm surcharging the index_sso.php file and mounting it as a readonly volume in the container :

/path/to/index_sso.php:/usr/share/zabbix/index_sso.php:ro

I have tied your solution but i have found few problems.

I have found that $baseurl uses Utils class from OneLogin plugin and that my X-Forwarded headers was wrong. My solutions was changing X-forwarding headers accordingly

$_SERVER['HTTPS'] = 'on';
$_SERVER['HTTP_X_FORWARDED_PROTO'] = "https";
$_SERVER['HTTP_X_FORWARDED_PORT'] = 443;
$_SERVER['HTTP_X_FORWARDED_HOST'] = "zabbix.example.com";
Utils::setProxyVars(true);

Hi,

Same problem here, I've a front reverse proxy (HAproxy) for zabbix like this:

Web browser — https ---> Haproxy — http ---> zabbix.

I needed to patch the index_sso.php file to add:
Utils::setProxyVars(true);
Otherwise, firefox would send me an alert when returning from keycloak.

The Utils::setProxyVars(true) workaround helped me as well. Some additional clarity:

• If you are using this solution, do not make any changes to the $settings array. It is not necessary to insert the "baseurl" key with this method. If you combine the methods described in this thread you may see an error about the SAML reply being received at the wrong URL.
• If you are using the docker container, copy the file out of the container to modify it:

  docker exec -u 0 zabbix-web cp /usr/share/zabbix/index_sso.php /usr/share/zabbix/index_sso.php.backup
  docker cp zabbix-web:/usr/share/zabbix/index_sso.php /tmp
  

• Insert your changes immediately prior to the definition of the $baseurl definition, like so:

  $_SERVER['HTTPS'] = 'on';
  $_SERVER['HTTP_X_FORWARDED_PROTO'] = "https";
  $_SERVER['HTTP_X_FORWARDED_PORT'] = 443;
  $_SERVER['HTTP_X_FORWARDED_HOST'] = "yourzabbix.example.com";
  Utils::setProxyVars(true);
  $baseurl = Utils::getSelfURLNoQuery();
  

• If you are using the docker container, copy the modified file back into the container and restart it.

  docker cp /tmp/index_sso.php zabbix-web:/usr/share/zabbix/index_sso.php
  docker restart zabbix-web
  

As I faced same problem recently, I sumbitted PR to zabbix repo to fix the issue: https://github.com/zabbix/zabbix/pull/22

Hi,

I had similar issues with Okta and the official zabbix-web-nginx-mysql container.  I'm running behind an NGINX reverse proxy, with zabbix at https://<base url>/zabbix

The URL that was passed from the container to Okta had "RelayState" set to the the base path of "/" and the port of 8443.  The value of RelayState was eventually used in a test against what the actual connection from the browser was, which would have been the https://<base url>/zabbix.  so both the port number and the base path mismatched.

I had gone in and manully changed things in the SAML php scripts to get things working, but finaly settled on created a file that I would mount inside the container (via the volumes section in my yaml file for docker-compose).

      - /opt/docker/zabbix-web/config/SAML_settings.php:/usr/share/zabbix/vendor/php-saml/src/Saml2/settings.php:ro

Like above, I was using the function calls that the SAML library made available.  But this way, I didn't need to modify any files inside the container.  I had to do one additional function call besides setProxyVars to describe my base path of "/zabbix/".

The SAML_settings.php file I created is as follows:

<?php
\OneLogin\Saml2\Utils::setProxyVars(true);
\OneLogin\Saml2\Utils::setBaseURLPath("/zabbix/");

With that file called settings.php, the SAML library would include those function calls, call them in the right namespace and the value of RelatState now matched the URL I would be connecting to from my browser.

I was working with 5.0.1 when I had the issue and I saw changes in git for index_sso.php related to Okta and pulled that file to try it, but it didn't solve the issue of having the container at a different base URL like I did, so I'm still using the method I'm describing with 5.0.2 and it works fine.

It took a long time to figure all of this out and I didn't find this thread until I had things working, but I thought I'd share my thoughts in the hopes it will save someone else some time.

I just looked at the pull request above; if that added ability to call the function  setBaseURLPath, it might eliminate the need to mount the  settings.php file like I described.

Closed as duplicate of ZBX-19320.