PMA SSO - User mistake or bug?

I’m reading in the release notes of [1.4.3] the enabling of phpMyAdmin Single Sign On support. That is great! :star_struck: But how exactly can the user or admin use it?

I’ve searched the docs for SSO and Single Sign On, but there seems to only explain the command line v-add-sys-pma-sso.

In GitHub I found @eris #1460 explaining the technical stuff. I understand that to use SSO, the first step would be to run v-add-sys-pma-sso on the command line. So I did and I got the output: PMA Hestia-SSO plugin has been succesfully installed (mind the small error in the word successfully which is missing an “s” :wink:)

After that I logged in the Web UI, clicked on the DB tab and I saw a new icon next to the edit button (pencil). Hovering this icon (which BTW has a wrong tooltip) I see that the URL, that will be visited if clicked, is as @eris described ( //hestia-sso.php?database=[user-db]&user=[user]&exp=[numbers]&hestia_token=[alphanumeric] ). The problem is that when clicking on that icon, the PMA page opens the Login screen. I would expect it to go directly to the DB inside PMA.

I noticed the double // before hestia-sso.php in the URL so I also tried with one / but that had the same effect. Just went to the login screen.

Am I doing something wrong?

Is Api enabled ?

Server → Settings → Updates → Enable Features → Save


Server → Settings → database and enable PHPmyadmin SSO feature

Yes. API Enabled (Settings > Security > System > Enable API access) with no IP restrictions.

Aha! Just enabled preview features. The password is empty in (Settings > Configure > Databases). Should I do something special with that?

I am still just getting the PMA login screen when I click on the Login to DB icon in UI.

This is the contents of the hestia/system.log while I was messing with PMA SSO

2021-06-16 12:00:36 v-revoke-api-key  '[alphanumeric_here]'
2021-06-16 12:00:36 v-change-sys-config-value  'PHPMYADMIN_KEY' ''
2021-06-16 12:00:36 v-delete-sys-pma-sso  'quiet'
2021-06-16 12:00:36 v-change-sys-config-value  'POLICY_USER_VIEW_SUSPENDED' 'yes'
2021-06-16 12:00:46 v-change-sys-config-value  'PHPMYADMIN_KEY' '[alphanumeric_here]'
2021-06-16 12:00:46 v-add-sys-pma-sso  'quiet'
2021-06-16 12:02:14 v-change-database-host-password  'mysql' 'localhost' 'root' '******'
2021-06-16 12:03:21 v-revoke-api-key  '[alphanumeric_here]'
2021-06-16 12:03:21 v-change-sys-config-value  'PHPMYADMIN_KEY' ''
2021-06-16 12:03:21 v-delete-sys-pma-sso  'quiet'
2021-06-16 12:03:42 v-change-sys-config-value  'PHPMYADMIN_KEY' '[alphanumeric_here]'
2021-06-16 12:03:42 v-add-sys-pma-sso  'quiet'

What is your setup? Nginx + apache2. The only thing that might be an issue is that that there is an difference between the ip you have on “hestia-nginx” and when you visit “phpmyadmin”

Correct. Nginx + apache + multiphp
The VPS I’m trying with (OpenVZ if that matters), has a single IP address.

Here is an interesting find inside apache logs:

[client_IP_here] - - [16/Jun/2021:12:04:02 +0300] "GET /phpmyadmin//hestia-sso.php?database=[db_here]&user=[user_here]&exp=1623834230&hestia_token=[alphanumeric_here] HTTP/1.0" 302 4144 "https://[server_FQDN_here]:[port_here]/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0"

[client_IP_here] - - [16/Jun/2021:12:04:02 +0300] "GET /phpmyadmin/index.php HTTP/1.0" 302 9991 "https://[server_FQDN_here]:[port_here]/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0"

[client_IP_here] - - [16/Jun/2021:12:04:02 +0300] "GET /phpmyadmin/hestia-sso.php HTTP/1.0" 302 605 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0"

The web server replied with status code 302 and then provide another URL for the browser to connect to. This explains why I’m seeing the login screen. But I have no idea why the web server replied like this. I need to dig more into it.

EDIT: I just edited this post to remove the actual client IP address and replace with placeholder text [client_IP_here].

Part where I alllready afraid of it.

serverip|clientip Should be a easy fix…

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.