Failed to set session cookie. Maybe you are using HTTP instead of HTTPS

[nik6018]

Steps to reproduce

1. Install PMA 4.8.0
2. Login via HTTP

Expected behaviour

After entering the login information, I should be able to log in

Actual behaviour

It doen't log me in and fails with this error : Failed to set session cookie. Maybe you are using HTTP instead of HTTPS In previous version of PMA 4.7.9 I didn't face this issue I was able to log in via HTTP and HTTPS without any issue. Now I am only able to login via HTTPS.

How can I disable this as I cannot find anything in the docs, the closest thing I was able to find is this Link

I am really confused about this.

I checked the file common.inc.php where this error is mentioned, but still wasn't able to figure out the issue.

Web Server configuration

  server{

    listen     2002;
    listen     2004;
    server_name  localhost;

    # The Document Root
    root    /custom/path;

    rewrite "/sess([0-9a-zA-Z]{16})/(.*)" /$2;

    # Redirect server error pages to the static pages
    error_page  404                 /nginx/404.html;
    error_page  497                 /nginx/497.html;
    error_page  500 502 503 504     /nginx/50x.html;        
    location ~ (index.php|/)$ {

        fastcgi_pass    unix:/usr/local/php/var/fpm9178.sock;
        if ($uri ~ "^/phpmyadmin/") {
            fastcgi_pass    unix:/usr/local/php/var/fpm9179.sock;
        }
        fastcgi_read_timeout 3600;
        fastcgi_index   index.php;
        fastcgi_param   SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        fastcgi_param   SCRIPT_NAME   $fastcgi_script_name;
        include         fastcgi_params;
    }

    location ~ \.php$ {
        fastcgi_pass    unix:/usr/local/php/var/fpm9178.sock;
        if ($uri ~ "^/phpmyadmin/") {
            fastcgi_pass    unix:/usr/local/php/var/fpm9179.sock;
        }

        fastcgi_read_timeout 3600;
        fastcgi_index   index.php;
        fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param   SCRIPT_NAME     $fastcgi_script_name;
        include         fastcgi_params;
    }

    client_max_body_size 50M;
}

Server configuration

Operating system: CentOS and Ubuntu

Web server: Nginx 1.12.2

Database: MySQL 5.5.59

PHP version: PHP 5.6.35

phpMyAdmin version: 4.8.0

Client configuration

Browser: Chrome, FireFox

Operating system: Windows

[ibennetch]

When you see the error, can you try logging in again? This workaround seems to function for me until we get this fixed.

[nik6018]

@ibennetch yes I tried this multiple times it doesn't work for me.

[ibennetch]

See also https://stackoverflow.com/q/49811804/2385479 for another person with this problem.

[nik6018]

Thanks for the link. But I have rechecked all the configuration files and modules they seem to be ok. Reinstalled 4.7.9 and everything works as it should. Will this be fixed in 4.8.1?

[nik6018]

@ibennetch In 4.8.0.1 I am only facing this issue in Chrome. FireFox and Edge work fine. It seems that during the initial request after entering the login details there is a 302 redirect which authenticates me in FireFox and Edge. That redirect is not happening in Chrome Can you give me a hint on how can I check and debug this?

[D-AIRY]

Same error in Firefox 59. In my case issue caused by javascript error which makes tracekit library to query server and rewrite cookies. As a quick workaround: edit file ./js/vendor/tracekit.js - add return in start of function traceKitWindowOnError

[voltel]

I have the same issue. Run http://phpmyadmin/index.php, provide MySQL valid credentials (not root, but with all privileges; and I tried root as well), have the same error message ("Failed to set session cookie. Maybe you are using HTTP instead of HTTPS to access phpMyAdmin."). So, I checked both FireFox 59.0.2 (64-bit) and Chrome 66.0.3359.117 - the error is reproduced in either browser.

As for suggested workaround (return in the beginning of the traceKitWindowOnError function in ./js/vendor/tracekit.js) - it didn't work for me.

Moreover, I tried manually create a config.inc.php and select other modes of authentication type (e.g. $cfg['Servers'][$i]['auth_type'] = 'config'; or $cfg['Servers'][$i]['auth_type'] = 'http';);

'http': doesn't work (looks like wrong credentials);

'config': php error:

Fatal error: Uncaught Error: Call to a member function exists() on null in D:\WebSites\phpmyadmin\libraries\classes\DatabaseInterface.php:1544 Stack trace: #0 D:\WebSites\phpmyadmin\libraries\classes\DatabaseInterface.php(2477): PhpMyAdmin\DatabaseInterface->postConnectControl() #1 D:\WebSites\phpmyadmin\libraries\common.inc.php(358): PhpMyAdmin\DatabaseInterface->connect(257) #2 D:\WebSites\phpmyadmin\index.php(26): require_once('D:\\WebSites\\php...') #3 {main} thrown in D:\WebSites\phpmyadmin\libraries\classes\DatabaseInterface.php on line 1544

So, this is dead-end for me. Waiting for new release.

PS. It may be obvious (not for me), but when I tried to configure the server in the setup, (renamed my config.inc.php to _config.inc.php just to hide it, and tried http://phpmyadmin/setup/), there was an indication in the GUI that "There are no configured servers". When I try to configure one by clicking the button "New server", it doesn't modify anything (when I click the button to show the resulting configuration).

[fraban]

Hi - I discovered exactly the same error when switching to 4.8.0.1 from 4.7.9 . Server is ubuntu 14.04 LTS with nginx/1.10.1 and 5.5.59-MariaDB-1ubuntu0.14.04.1
Testing with phpMyadmin 4.8.0.1 exactly the errors reported here. Going back to 4.7.9 everything is working again. I can reproduce with Firefox and Safari - Chrome not tested

[williamdes]

Thanks to @ntinti https://github.com/phpmyadmin/phpmyadmin/issues/14219#issuecomment-385626406 this is the reason for this error (Call to a member function exists() on null):

Reproduce

-- Random IP
UPDATE mysql.db SET host='127.1.2.1' WHERE Db='phpmyadmin';
FLUSH PRIVILEGES;
-- Now phpmyadmin fails on login : HTTP ERROR 500

-- Assuming host was % before
UPDATE mysql.db SET host='%' WHERE Db='phpmyadmin';
FLUSH PRIVILEGES;
-- Now phpmyadmin succeeds on login

Stacktrace

2018/05/01 17:25:33 [error] 4492#4492: *729 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to a member function exists() on null in /mnt/Dev/phpmyadmintest/libraries/classes/DatabaseInterface.php:1588
Stack trace:
#0 /mnt/Dev/phpmyadmintest/libraries/classes/DatabaseInterface.php(2544): PhpMyAdmin\DatabaseInterface->postConnectControl()
#1 /mnt/Dev/phpmyadmintest/libraries/common.inc.php(352): PhpMyAdmin\DatabaseInterface->connect(257)
#2 /mnt/Dev/phpmyadmintest/index.php(26): require_once('/mnt/Dev/phpmya...')
#3 {main}
  thrown in /mnt/Dev/phpmyadmintest/libraries/classes/DatabaseInterface.php on line 1588" while reading response header from upstream, client: 127.0.0.1, server: localhost.localdomain, request: "POST /phpmyadmintest/index.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.2-fpm.sock:", host: "localhost.localdomain"

[AlviseNicoletti]

This solution is not working for me, however, I want to clarify my situation:

I have phpmyadmin 4.7.9 perfectly working, when I upgrade to 4.8.0.1 (removing and then copying new files except config.php) I get this error.

[nik6018]

As stated in #14234 Login via HTTP works if in private mode, but doesn't work in normal session. I tried to clear the cookie for the domain but still the same issue.

[COLABORATI]

Things like login are not tested with this software before a release? Interesting to know!

[nik6018]

@ibennetch Can you please update us with any planned fix for this?

[ibennetch]

@nik6018 Sure, I can make a comment about this.

I hope this is fixed for the next release. In fact, I've held back releasing 4.8.1 because of this bug and #14220. I haven't, personally, had time to look in to either of these issues and I can't speak for anyone else on the development team, but it seems everyone else is quite distracted as well. Since this is a severe problem, I have set the target milestone to 4.8.1, which doesn't assure us that it will be fixed for the release of 4.8.1, but it indicates our desire to have this fixed before the next release. We regret that this bug affects you and wish it weren't in a release version.

[ibennetch]

To address the concern raised by @COLABORATI, yes of course we test the code before release, in fact I use the development version nearly every day and have found many bugs before they were released. I know many of the other developers also use the development version often. In addition, we have a series of automated tests that run before a release is created and after each new code commit is added to the repository; in the case of this bug none of those tests caught the bug. I'm still not able to reproduce it (other than occasionally needing to resubmit my username and password when logging in, which isn't even exactly what is being reported here). So testing such as you propose is performed, but did not catch this particular instance.

[AlviseNicoletti]

I'm in a worse scenario ... if I update to current version I just have fatal errors.

I don't understand ... fresh install works, but I can't update even deleting phpmyadmin tables.

[ibennetch]

I don't think setting the secure option for session_set_cookie_paramsto false is ideal.

Based on comments from nik6018 and others, it seems the problem continues even if the cookies are cleared, which really eliminates a lot of the obvious causes that I see. Without having a clear way to reproduce this or seeing a clear cause, it's difficult to pinpoint the problem without spending more time on it directly. Of course, this is a high-priority problem, but I don't have any answer yet.

As a workaround, you should be able to edit libraries/common.inc.php and comment out lines 188-196, the if block beginning with if (isset($_POST['set_session']) && $_POST['set_session'] != session_id()) {.

[gavtaylor]

Ive been getting this error since upgrading to 4.8.0 as well but I dont access via http, my install is https only.

the message is being triggered when trying to login after a session has expired, opening the login page in a private tab logs in first time. a standard tab errors on first attempt, logs in on the second.

[gavtaylor]

no it logs in first time on private tabs, standard tabs login first time too if I log out and open a new window. its just the expired session triggering this error for me.

I just wanted to mention that my install is HTTPS only, everyone commenting so far has mentioned they also login via http.

I use Firefox (dev edition) but have tested in chrome (stable) as well in case it was a brwoser niggle.

[zangwill]

In my case, I disabled the chrome extension Katalon Recorder (Selenium IDE for Chrome) and it fixed.

[nuxwin]

When login the first time through HTTPS, a secure cookie is set... The problem is that if an user logout and then attempt to login again through HTTP, that will fails because there is already a secure cookie set that of course cannot be sent through HTTP. Same behavior occurs for a session timeout when an user need login again. Basically, if a secure cookie is set, user will have to login through HTTPS only.

There are some browsers allowing setting secure cookies via HTTP protocol but that is a wrong behavior which has been recently deprecated (For instance: FF 52).

There are not reliable solution here. Once the secure cookie is set and if an user want login through HTTP, it will have to remove the secure cookie first. The annoying thing is that you cannot unset a secure cookie for a specific domain via HTTP protocol... The only solution I see here is to set specific session name for both HTTP and HTTPS but this could lead to side effects I think.

[dinodan]

In file "libraries/common.inc.php" change: $token_mismatch = ! @hash_equals($_SESSION[' PMA_token '], $_POST['token']); to $token_mismatch = false; //! @hash_equals($_SESSION[' PMA_token '], $_POST['token']);

If you still have javascript error, change file name "js/vendor/js.cookie.js" to "js/vendor/jscookie.js" and in file "libraries/classes/Header.php" change: $this->_scripts->addFile('vendor/js.cookie.js'); to $this->_scripts->addFile('vendor/jscookie.js');

I know, this is not perfect solution, but for localhost is good enough.

[svivian]

I had the same issue, where PMA just wouldn't log in at all. Turns out it was uBlock Origin preventing the file /js/vendor/js.cookie.js?v=4.8.2 from loading. After disabling the ad blocker everything works fine.

[ghost]

Can confirm, for me it was uBlock Origin blocking js/vendor/js.cookie.js?v=4.8.2. Source seems to be Fanboy’s Cookiemonster List. Hitting "Purge All Caches" and "Update Now" in the "Filter Lists" settings page of uBlock seems to have fixed it for me without needing to disable the list entirely.

[cochrasc]

@Zangwill You've saved me from going bald. I've been pulling my hair out for months trying to figure it out. For me, this issue also turned out to be because of the Katalon Recorder (Selenium IDE extension).

[williamdes]

Param	Value
Error Type	User Error
Error Message	Failed to set session cookie. Maybe you are using HTTP instead of HTTPS to access phpMyAdmin.
Exception Type	php
phpMyAdmin version	4.8.4
Incident count	1
Link	Report#54621

This comment is posted automatically by phpMyAdmin's error-reporting-server.

[nPHYN1T3]

I have this issue as well in 4.8.4. Private tabs work, normal do not (in any browser). My primary is Firefox 64.0.

This is obnoxious because not only am I constantly having to log back in but I will have to refresh the page before I login. So I will be idle too long, go to do something and it will kick me back to a login with the error. If I login, error. However if I refresh the page before trying to login it works.

[zx950921]

I also have this problem in the normal mode of Google Chrome, but when I log in through the seamless browsing mode of Google Chrome, this problem no longer occurs, which may be caused by a conflict with one of my browser plugins.

I manually closed the plugin test of Google Chrome and found that it was caused by the Tampermonkey plugin. I manually tested the script enabled in Tampermonkey and found that it was caused by a conflict between a script and phpmyAdmin. After I disabled some scripts in Tampermonkey. It’s normal

[voltel]

Dear fellow php programmers,

May I share with you the solution I have found to this problem of ours. As I understand, there might be a multitude of reasons all of which are having the same misleading presentation – the infamous "Failed to set session cookie. Maybe you are using HTTP instead of HTTPS" error. So, I guess at least some of you could possibly have the same problem root cause as I had, so the following solution may be of help. I work under Windows 10, use Firefox 65.0, PHP version 7.1.6, Apache 2.4.26, MySQL 5.7.18, just to give you the context.

After many experiments, I just happened to have PhpMyAdmin 'http' authentication work fine, under php development server, with url having 'http://' schema. Simply speaking, I issued a command in the terminal (d:\WebSites\phpmyadmin>php -S 127.0.0.1:80), changed in phpmyadmin configuration file ("config.inc.php") authentication type to 'http', issued in the browser address bar 'http://phpmyadmin/', got a login form and was able to authenticate into my MySQL account.

But, when I was trying to do the same under Apache, this misleading error message about problem with setting cookies presented itself. So, I went to see the cookies that had been set under the development php server, and I found them under the Storage/Cookies tab of WebDeveloper Inspector. When I repeated this operation to see the cookies set under Apache server, I noticed the strangest thing: the path on the set cookies was not an expected "/" but a "/D:/".

So, I dived into the phpmyadmin code to find the code setting the cookies, one thing led to the other, and I found in "libraries/config.default.php" file this configuration parameter – "PmaAbsoluteUri" – the first of the TON of them with the following description (excerpt):

In most cases you can leave this variable empty, as the correct value will be detected automatically. However, we recommend that you do test to see that the auto-detection code works in your system.

So, guess what, I set the parameter to 'http://phpmyadmin/' along with other "usual configuration parameters:

$cfg['PmaAbsoluteUri'] = 'http://phpmyadmin/'; $cfg['Servers'][$i]['auth_type'] = 'cookie'; / Server parameters / $cfg['Servers'][$i]['host'] = 'phpmyadmin'; $cfg['Servers'][$i]['compress'] = false; $cfg['Servers'][$i]['AllowNoPassword'] = false;

Just to give more context, I had "phpmyadmin" domain name declared in my "C:\Windows\System32\drivers\etc\hosts":

127.0.0.2 phpmyadmin pma

And in "D:\Apache24\conf\extra\httpd-vhosts.conf" file the most usual:

\<VirtualHost phpmyadmin:80> DocumentRoot "${DOCROOT}/phpmyadmin" ServerName phpmyadmin ServerAlias pma ErrorLog "logs/pma-error.log" CustomLog "logs/pma-access.log" common

\<Directory "${DOCROOT}/phpmyadmin"> Options Indexes FollowSymLinks AllowOverride Indexes Require all granted FallbackResource /index.php \</Directory> \</VirtualHost>

That's it. The 'cookie' authentication works under Apache too. Hooray! But... The 'http' authentication stopped working; this needs more debugging but currently doesn't bother me much.

I hope, the PhpMyAdmin developers will notice this post and react appropriately.

[sangyuxiaowu]

Set $cfg['PmaAbsoluteUri'] = '' in config.inc.php; the value is the path to the phpmyadmin url you are accessing in the browser. For example, I forwarded the address to the private network via the nginx proxy $cfg['PmaAbsoluteUri' ] = 'https://192.168.1.10/db/'; Nginx is configured as

server {
        listen       443 ssl http2;
        server_name  192.168.1.10;

        ssl_certificate      server.pem;
        ssl_certificate_key  server.key;

        ssl_session_cache    shared:SSL:50m;
        ssl_session_timeout  5m;

        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;

        #access_log  logs/host.access.log  main;
        #access_log  "pipe:rollback logs/host.access_log interval=1d baknum=7 maxsize=2G"  main;

        location /db/ {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass   http://127.0.0.1:8080/workspace/phpMyAdmin/;
            index  index.html index.htm;
        }
}

[osc2nuke]

I figured out that chrome extensions can be a cause for this problem. In my case it was the safe torrent scanner chrome extension. Very interesting that such can produce a bug like this. I do not think it is a phpMyAdmin issue.

[williamdes]

I do not think it is a phpMyAdmin issue.

Trust me, it is (and is not, because It is an issue with secure cookies)

@osc2nuke Can you explain how to reproduce this issue from scratch using the extension that from what you said "can produce a bug like this."

Original comment: https://github.com/phpmyadmin/phpmyadmin/issues/14219#issuecomment-384737556

°1

• Open a private navigation
• Login using HTTP
• Success !

°2

• Open a private navigation
• Login using HTTPS
• Success !
• Please CLOSE THE WINDOW

°3

1. Open a new private navigation
2. Login using HTTPS
   • Success
3. Login using HTTP
   • Error !

[williamdes]

Original comment: https://github.com/phpmyadmin/phpmyadmin/issues/14219#issuecomment-384757638 As explained in https://security.stackexchange.com/a/140944 Secure Cookies are not sent by HTTP. So if you first create the cookies on HTTPS you wont be able to send them to phpMyAdmin on HTTP. They will be rewritten at each login, not sent back to the server.

[ibennetch]

There are many people here who have experienced this problem; can several of you try the pull request at https://github.com/phpmyadmin/phpmyadmin/pull/15273 to see if this fixes your problem?

[williamdes]

Just note that the PR #15273 will not solve the issue : the session expired and so the token is invalid when submitting the form, reloading and submitting the form another time fixes the issue

[williamdes]

I had Safe Torrent Scanner enabled on my Vivaldi (chromium based) and it created this issue everywhere .. Disabled it. Needs more investigation in the codebase of Safe Torrent Scanner (maybe reverse engineering needed here)

[rangka-kacang]

Hello.

I can't believe this is still not fix after a year. I asked about this issue last June and still looking for an answer.

https://stackoverflow.com/questions/50968326/failed-to-set-session-cookie-maybe-you-are-using-http-instead-of-https-to-acces

My hack at the moment is to simply not use $cfg['Servers'][$i]['auth_type'] = 'cookie'; at all.

[Pantyboy]

I too have had this problem for over a year. I thought it would be rectified with each update but, here we are, 12 months on and still the problem exists.

I get around it by using Microsoft Edge. Why doesn't that have this problem?

[williamdes]

@Pantyboy what browser are you using and what extensions are enabled?

[nPHYN1T3]

I really wish the "which browser and which extensions" question would crawl in a ditch and die. I've tested this on virtually every browser you can list with and without extensions and the problem is always there. I have a VM with every browser still being actively worked on I can install all clean, no extensions, no tweaks or setting changes that I test things with.

I've also noticed a problem with how it redirects after login which makes me think it's got a path issue somewhere I've not been able to find. Either way the browser or extensions aren't the issue.

Edge is most likely doing something wrong that comically bypasses the failure. This may be convenient but unsafe. Even Microsoft has stated Edge isn't a complete browser and lacks most the basic security and safety features you should have online, hence why it's probably ignoring the security checks and "works." Edge isn't a full / proper browser and IE is woefully outdated and dead so I've never tested on either.

[williamdes]

@nPHYN1T3 okay, can you tell us more about your server setup? proxy?

[nPHYN1T3]

It's a server, no proxy...enlightening! Sorry dealing with so many technical issues lately I'm starting to get fed up. Not much to tell. All I can really say since I've forgot most of the things I've looked into or tried since this problem has persisted so long is that if I say make a fake domain in my hosts file on a client machine and a fake vhost for the pma folder it fails but when I log in again it redirects to the correct folder. If I say then access that same install from the path i.e. the machine ip/pmaFolder the https cookie still fails but upon logging in again it will redirect to the server root. Clearly something in the login routine is losing or doesn't understand it's path which could be part of the cause for the cookie to not be accessible. I wish I had more to say but again this has gone on so long I just gave up. I've forgot all the config tweaks, I just don't have time for this BS. I just keep logging into the idiotic thing. I have other projects and issues that are higher on the priority list. In fact I'm just accepting this is broken and muting the thread.

[Pantyboy]

@williamdes I using Firefox 68.0.1 (64bit). I'm using Apache 2.4.39 (Win64), php 7.3.7, MySQL 5.7.19 and phpmyadmin 4.9.0.1 on Windows 10 Home 64bit.

I have tried using Firefox (with and without extensions), Chrome (same). Both these browsers have the same issue. Internet Explorer and Edge do not.

phpmyadmin used to work on Firefox with extensions. What has happened in the last year?

My config.inc.php hasn't changed, nor has my httpd.conf and php.ini.

[apzentral]

I figured out that chrome extensions can be a cause for this problem. In my case it was the safe torrent scanner chrome extension. Very interesting that such can produce a bug like this. I do not think it is a phpMyAdmin issue.

I also have the same issue. Once I turn off the "Safe Torrent Scanner" plugin, it now working again.

[williamdes]

Thanks to https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin Here is the source code of "Safe Torrent Scanner" aegnopegbbhjeeiganiajffnalhlkkjb.zip

If someone finds what is wrong faster than me, post it here ;)

[rangka-kacang]

I’m pretty sure this has nothing to do with Chrome extension. It’s been awhile since I last use the cookie setting. I’ll test this in the next morning and let you guys know the soonest. This bug was reported since Nginx 1.12 and PHP5 but now it’s already like what? Nginx 1.17 and PHP7 yet the bug is still here. We need a better insect repellent equipment... since I’m on Ubuntu and running 4.9.0.1 with mariadb 10.4 i’ll setup a vm to see if this is still the case, otherwise it’s a windows thing 😂

[williamdes]

@rangka-kacang I would not be so sure, I had the issue with the extension and also without But this issue can be reproduced by very different factors

I looked at the the code of the extension and it does very strange things with 'set-cookies' instructions

[rangka-kacang]

I've tested this just now and I can't produce it anymore. My environment are as follows (and is a fresh install, no extensions, nothing, just stock iso):

ubuntu@ubuntu:~$ uname -a
Linux ubuntu 5.0.0-27-generic #28~18.04.1-Ubuntu SMP Thu Aug 22 03:00:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@ubuntu:~$ lsb_release -d
Description:    Ubuntu 18.04.3 LTS
ubuntu@ubuntu:~$ mariadb -V
mariadb  Ver 15.1 Distrib 10.4.8-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
ubuntu@ubuntu:~$ nginx -v
nginx version: nginx/1.17.3
ubuntu@ubuntu:~$ php -v
PHP 7.3.9-1+ubuntu18.04.1+deb.sury.org+1 (cli) (built: Sep  2 2019 12:54:24) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.9, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.9-1+ubuntu18.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies

I have this on my config.inc.php:

<?php
$cfg['blowfish_secret'] = 'hidden';
$cfg['Servers'][1]['auth_type'] = 'cookie';
$cfg['Servers'][1]['host'] = 'localhost';
$cfg['Servers'][1]['compress'] = true;
$cfg['Servers'][1]['AllowNoPassword'] = false;
$cfg['Servers'][1]['controluser'] = 'hidden';
$cfg['Servers'][1]['controlpass'] = 'hidden';
$cfg['Servers'][1]['pmadb'] = 'phpmyadmin';
$cfg['Servers'][1]['bookmarktable'] = 'pma__bookmark';
$cfg['Servers'][1]['relation'] = 'pma__relation';
$cfg['Servers'][1]['table_info'] = 'pma__table_info';
$cfg['Servers'][1]['table_coords'] = 'pma__table_coords';
$cfg['Servers'][1]['pdf_pages'] = 'pma__pdf_pages';
$cfg['Servers'][1]['column_info'] = 'pma__column_info';
$cfg['Servers'][1]['history'] = 'pma__history';
$cfg['Servers'][1]['table_uiprefs'] = 'pma__table_uiprefs';
$cfg['Servers'][1]['tracking'] = 'pma__tracking';
$cfg['Servers'][1]['userconfig'] = 'pma__userconfig';
$cfg['Servers'][1]['recent'] = 'pma__recent';
$cfg['Servers'][1]['favorite'] = 'pma__favorite';
$cfg['Servers'][1]['users'] = 'pma__users';
$cfg['Servers'][1]['usergroups'] = 'pma__usergroups';
$cfg['Servers'][1]['navigationhiding'] = 'pma__navigationhiding';
$cfg['Servers'][1]['savedsearches'] = 'pma__savedsearches';
$cfg['Servers'][1]['central_columns'] = 'pma__central_columns';
$cfg['Servers'][1]['designer_settings'] = 'pma__designer_settings';
$cfg['Servers'][1]['export_templates'] = 'pma__export_templates';
$cfg['UploadDir'] = 'tmp';
$cfg['SaveDir'] = 'tmp';
$cfg['TempDir'] = 'tmp';
$cfg['ShowAll'] = true;

I have no problem accessing and logging in via localhost. I'm using phpMyAdmin 4.9.0.1 from https://files.phpmyadmin.net/phpMyAdmin/4.9.0.1/phpMyAdmin-4.9.0.1-all-languages.zip and Google Chrome Version 77.0.3865.75 (Official Build) (64-bit) from the official repository deb [arch=amd64] https://dl.google.com/linux/chrome/deb stable main -- Tested on both normal and incognito, no problem.

[emmanuelkolawole4]

hello, i just started using laragon and i'm getting the error: There is mismatch between HTTPS indicated on the server and client. This can lead to non working phpMyAdmin or a security risk. Please fix your server configuration to indicate HTTPS properly.

please could someone walk me through solving this problem?

[dausruddin]

I am using squid proxy (latest) and phpmyadmin refusing to work on it. Also when I left the tab for some time and it logged out, it will give the same error when I hit login button. Refreshing webpage seems to fix it, but I am hoping for a permanent solution.