Idea for new versio: Auto login in phpmyadmin and subdomain maker

I have two ideas for the next version. One idea is convenience (I never found a solution)
When I want to add a subdomain to have a menu / icon to the domain Add a new subdomain (as in cPanel)

The second idea is related to security and convenience. Now any client who wants can access PHPMyAdmin (can be limited to .htaccess) but it is not practical, for example: http: // IP / phpmyadmin /

For this purpose (security), for example, it can be done IF the user, not registered in Hestia, does not have access to this directory. Do not open. The other is (convenience) when you press the panel to open PHPMyAdmin Hestia it will automatically log you in something like a ‘root’ account, which gives you access to all the databases it has added.

Both ideas are borrowed from cPanel, I think they will be useful to us.

After almost 1 week of puzzles with DNS servers, I can say that Hestia is a WONDERFUL SOLUTION! I will release a donation if there is a place for the project.

Postscript: The idea of ​​PMA also applies to listing (automatically) on the Roundcube page

I also did not see a user (not an administrator) from where he can change the PHP version / PHP INI Editor of a domain or (if there is a way to add) a subdomain

For PHP my Admin Single Sign on go to settings enable preview settings: (Updates)

Save

Then Databases

Set to enabled:
Hestia does not have a difference between “Subdomain” and “Web domain” They are always treated the same…

For PHPmyadmin we have introduced a feature: PHPmyadmin SSO to enable it go to /edit/server/

And save

The go to List database and click on a database

Screenshot 2021-08-30 at 23.49.18

Title still is edit database but it forwards you to phpmyadmin and login. It will create a temp user and deletes the user after 30 min of in activity. This users has currently only access to 1 database.

Please not api needs to be enabled…

For Roundcube / Rainloop we denied the same request as we don’t think it is possible without introducing security issues. It needs to be done by passing trough the login data as we can’t create a “second” user with extra permissions for that mailbox. For the mail user that we currently don’t save locally (Only hashed)

You can edit template / php version by selecting the templates:

Screenshot 2021-08-30 at 23.49.18

1 Like

I have now activated the specified settings, but pressing the login button for the database simply takes me to the phpmyadmin page for login.

Are you considering external (unregistered in HestiaCP) users not having access to http: // IP / phpmyadmin - outsiders should not see this page (personal opinion) and should be restricted in a different way from … just some .htaccess - i dont like this idea for .htuser/.htaccess

And one more thing I don’t see an option to disable / activate mod_security or add any specific rules for a specific domain or folder, is such an implementation expected? It is also useful

I’m considering creating an integration for CentOS over time, as my idea is to be just a “foundation” that can then be upgraded. I will post it in the forum probably in a month or two. I hope it is useful for all of us :innocent: :slight_smile: :yum:

This should be already the default, but for apache2+nginx it is still working - known issue.

Currently not, no.

There has been already done some work which has been merged to the main branch for support centos/rpm systems including building the heszia rpm packages. But it has been postponed, due to the fact that centos is basicly a beta version now due to redhat decission and we currently not have enough resources to bring compatibility to all modifications we done with hestia - still a lot of work pending. Checkout the github project if you want to help out with rpm support.

1 Like

So, has anyone managed to run mod_security and manage it differently for each domain through Hestia? Sounds like you useful idea l? :hugs:

In the meantime, I still have a problem with PHPMyAdmin automatic login despite updates and restarting services. Where to look for the problem? :frowning:

Hestia is not that extensive… Also for sure not managed via Hestia maybe via config files…

PHPmyadmin auto login is mostly caused due to differences with ip what “Hestia” sees and “PHP” gets…

I do kind of like the idea of only allowing access to PHPmyadmin if you’re logged into the control panel. It has always worried me a bit that the admin interface has been open to the world, and I personally always make sure I change the default url from /phpmyadmin/ and also add Apache Basic Auth via an .htpasswd file. But I wouldn’t need to do that if it was limited to people logged into Hestia.

As a related piece of information, whereas previously phpmyadmin would not allow login by root user, it does now, perhaps because we’re using the ‘direct install’ rather than the .deb packages. So with that login, and the password you find in /root/.my.cnf you can access all databases on the server.
I mention this because a) it might be convenient for server administrators to know and b) it might cause them to consider the security implications.

1 Like

PHPmyadmin also allowed login via root in the past versions…

The idea was to keep any “errors” to the users as small as possible. I have fixed a bug in v-change-sys-api and hestia-sso.php got some more error reporting inserted:

For example:
[Thu Sep 02 12:46:55.499987 2021] [proxy_fcgi:error] [pid 6865:tid 140523234895616] [client 84.82.33.184:0] AH01071: Got error ‘PHP message: PHP Warning: Unable to connect over API please check api connection in /usr/share/phpmyadmin/hestia-sso.php on line 55’, referer: https://dev.eris.nu:8083/list/db/

Pull request:

I still have a problem with the automatic login to phpmyadmin (although all the updates on the panel). How are your colleagues? Does this automatic input work correctly?

You can store your sessions in a database that both applications connect to and then keep a record of your active session in a cookie. You will of course have to validate the cookie data to make sure it is not spoofed by storing client data in your session table at the time of creation and then match it against the connecting client when you load up the session in a different app, etc.

APP #1 (HESTIA)

user connets
user logs in (create cookie with client specific identifiers and specific crypt+salt)
user does what ever they need to in App #1

APP #2 (phpmyadmin)

user comes to App #2 while they have a session cookie from App #1
App 2 recognizes the cookie and checks  to see if their session is active and if their IP / browser matches the previous auth
if everthing checks out, consider the user’s session active
do what you need to do

Does that even remotely make sense?

P.S. The cookie is encrypted in an X way (via a somersault) that speaks between the two applications and the code is ready for this redirect (limited access to the login part of the PMA). I already did it for me. The only thing I expect in the future as a problem is … when the phpmyadmin update, the check will be deleted, but I think I can make a decision that checks the file if these lines exist and if the answer is - NO, just add them.

P.S.2
By the way, this automatic login via SSO, which was added by Hestia after all the updates, still doesn’t work for me. Any recommendations? How do I check if I have logged an error?

Disable and enable SSO and try again I have added some debug information for it…

trigger_error('Access denied: There is a security token mismatch '. $time, E_USER_WARNING);

For example…

And use it and check the error logs of the domain used…

What APP#1 and APP2 exactly does is the same the only “difference” is that we don’t use the same username / password but create a new “one” user so we don’t interfere with the current user / password because we don’t use it…

I am not able to see on your server what is going and what is going wrong on your server. Unless you provide me with more information

Check your logs /var/log/apache2/domain/panel.domain.com.error.log

Thanks for the log.

Between this is my crypt for cookie.

<?php
$simple_string = "Welcome to Phpmyadmin\n"; // Store a string into the variable which need to be Encrypted
echo "Original String: " . $simple_string; // Display the original string
$ciphering = "AES-128-CTR"; // Store the cipher method
$iv_length = openssl_cipher_iv_length($ciphering); // Use OpenSSl Encryption method
$options = 0;
  
$encryption_iv = '1234567891011121'; // Non-NULL Initialization Vector for encryption
$encryption_key = "keyforcrypt"; // Store the encryption key
  
$encryption = openssl_encrypt($simple_string, $ciphering, $encryption_key, $options, $encryption_iv); // Use openssl_encrypt() function to encrypt the data
  
echo "<br />Encrypted String: " . $encryption . "\n"; // Display the encrypted string
  

$decryption_iv = '1234567891011121'; // Non-NULL Initialization Vector for decryption
$decryption_key = "keyforcrypt"; // Store the decryption key
  

$decryption=openssl_decrypt ($encryption, $ciphering, $decryption_key, $options, $decryption_iv);// Use openssl_decrypt() function to decrypt the data
  

echo "<br />Decrypted String: " . $decryption; // Display the decrypted string
/*
Output:
Original String: Welcome to Phpmyadmin
Encrypted String: kRdl8B438pr79ymixIae9EbSlLHjeQ==
Decrypted String: Welcome to Phpmyadmin 

*/
?>

If anyone still wants I will share how it can be done so that if the user in Hestia is not logged in, there is no access to PMA. (Kind of like a lesson.)

Colleague @eris , I am working to find out the problem with SSO. Thanks for the guidance.

We don’t store the password of mysql users in our database so unless we change it… And we don’t want to do it…

We create a temporary and delete the user after xx min

2 Likes

I also do not create a user. I just encrypt the cookie so that even a “hacker” can try to manually add the cookie to be dropped from the directory. Maybe either I’m not expressing myself exactly what I’m doing or maybe we’re talking a different language between us.

I give an example once again (specify: I do not mean SSO in this example)
User X logs in Hestia, tries to open http: // ip / phpmyadmin - and opens it enters your password / user and logs in

User X is not logged in to Hestia, tries to open http: // ip / phpmyadmin - and is transferred to the Hestia control panel because it is not logged in.

How does the idea work? In Hestia When entering we remember a cookie: accesstopma
This cookie has respectively: validity time (as is the validity for login to hestia). This cookie is generated + back flip.

In PMA (index.php) I have added a code that checks X client if a cookie has been created (if it does not return to the panel), if there is it checks its validity (if it is not valid it goes back to the panel) if it is valid, but the time has expired (as it is saved it is returned to Hestia again), if it is valid and the time that is saved is OK, then we run the client to the login option in PMA.

Postscript:
Regarding SSO, I’m now starting tests on why it doesn’t work on my servers

It can be added to the Control Panel to invent some Salt in the future and so each version will be synchronized with different SALT (respectively security).

This is the error that occurs:
[Sat Oct 09 12: 01: 28.029984 2021] [proxy_fcgi: error] [pid 2104: tid 139748001625856] [client 111.222.333.444:0] AH01071: Received error "PHP message: PHP Warning: Cannot connect via API, please check the api connection in /usr/share/phpmyadmin/hestia-sso.php on line 55 ’
[Sat Oct 09 13: 09: 01,666056 2021] [proxy_fcgi: error] [pid 2104: tid 139748043589376] [client 111.222.333.444:0] AH01071: There is an error message „PHP message: PHP Warning: Cannot connect via API, please check api connection in /usr/share/phpmyadmin/hestia-sso.php on line 55 ’
[Sat Oct 09 13: 20: 26.212813 2021] [proxy_fcgi: error] [pid 2104: tid 139748077160192] [client 111.222.333.444:0] AH01071: There is an error message „PHP message: PHP Warning: Cannot connect via API, please check the api connection in /usr/share/phpmyadmin/hestia-sso.php on line 55 ’

/var/log/apache2/error.log - this is the correct file.

Check if the api is enabled

If enabled try adding server ip to the allowed IP address…

1 Like

I had given access to the API from another server also with Hestia. Now I added the IP address of the server I am testing and the SSO is already working. Thanks for the wink in the log file and the solution to the problem.