phpinfo(): https://9f90ee4ff90ff8cfd7e92e868a2cb34dcef5c1af.googledrive.com/host/0Bz6u7VbwRxguMklLNm4xcHJwSW8/index.html
Basically, on the 4.2.4 version I can't login, the page just refreshes without any error and the token changes. No errors in logs.
Every previous versions work.
In phpMyAdmin's doc, Requirements section: "When using the cookie authentication (the default), the mcrypt extension is strongly suggested for most users and is required for 64–bit machines."
Does this help?
I've installed php5-mcrypt and the issue still exists.
The log in page refreshes, the token changes, no errors are shown.
4.2.3 and 3.5.8.1 are working fine.
Did you restart Apache ? Did you delete your phpMyAdmin-related cookies?
Yeah I did even restart my computer.
Now I made a virtual machine with Ubuntu 14.04, installed php5-mcrypt, apache2, php5, mysql-server and there's same issue.
I have same issue on:
mac os x 10.9.3
PHP 5.4.24
MySQL 5.6.19
My config.inc.php:
$cfg['Servers'][$i]['verbose'] = '';
$cfg['Servers'][$i]['host'] = 'localhost';
$cfg['Servers'][$i]['port'] = '';
$cfg['Servers'][$i]['socket'] = '';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = '***';
/ End of servers configuration /
$cfg['blowfish_secret'] = '53a8be3376a5d2.01065676';
$cfg['DefaultLang'] = 'en';
$cfg['ServerDefault'] = 1;
$cfg['UploadDir'] = '';
$cfg['SaveDir'] = '';
Same issue here on debian-wheezy with pretty much a standard configuration. Tried debugging (mysql, session/cookies, php modules etc) for an hour or so, then downgraded. 4.1 worked instantly.
What I found out is that, after trying to log in to 4.2.4, the connection counter in mysql does not increase, so no connection is established, although I tried a couple of things to persuade pma otherwise (changing tcp/socket, localhost/hostname/port, AllowRoot).
Last edit: z0de 2014-06-24
I have no problem with 4.2.4 on Debian Wheezy.
@z0de: what about 4.2.3 in your case?
I changed two things in the meantime: I added a user root@% and I removed bind-address=127.0.0.1 in my.cnf. Now it works with every version of pma. Don't even know if this is connected to the issue.
The weird thing is that there was no error message, just like Jakob described in his intial post.
Last edit: z0de 2014-06-24
@z0de: thanks for the feedback; did you have the chance of trying 4.2.3 with your original configuration?
No, I haven't.
Btw: As it turned out, our administrator changed a couple of things, too, while we were trying to get PMA to work - he said, he updated all PHP modules. Maybe it was mcrypt-related after all. Is there no particular error message when mcrypt is missing or it has some 64bit-related issues? Because if that's the case, I think I know what happened here...
Thanks anyway.
I've just had this same issue (Mac OSX 10.9.3, PHP 5.3.27, mysql Ver 14.14 Distrib 5.6.13).
Checking out the 4.2.3 tag works fine - in fact when I reloaded I was already logged in. So in 4.2.4 it appears that submitting the login form does everything it's supposed to do, but when loading the page it doesn't detect you're logged in, and shows the login form page.
I would like to reproduce this problem, but I cannot. I just tested phpMyAdmin 4.2.4 with PHP 5.3.28, MySQL 5.6.15, the mysqli extension (of course) and mysqlnd. Under Iceweasel (Firefox) 24.6).
When I test, I take care of not having tested a previous phpMyAdmin version in the same session. Not sure how you are testing.
OK delved into this a bit more - turns out my mcrypt extension wasn't linked properly on my machine. With mcrypt up to date and enabled, I can log into PMA version 4.2.4.
But I don't think you should have changed the requirement for mcrypt in a minor version. 0.0.1 versions are supposed to be bug-fix only, not backwards-incompatible changes.
@Disgruntled Goat: thanks for the feedback. Note that the requirement has been there for a long time, but I suspect that this change of logic caused the new behavior:
https://github.com/phpmyadmin/phpmyadmin/commit/7cba81de271d62bdf93ded7598709702a96f92d7
You seem to be running from git, can you confirm that this commit changed the behavior for you? (you'll have to put back the incorrect mcrypt).
@z0de: there is a warning if the mcrypt_encrypt() function is not detected, but this warning can be disabled in your configuration (it's enabled by default). But maybe in your case, the function was present and misbehaving due to a mismatch in a library.
I ran into the same issue with 4.2.4 login today. Using Mac OS X 10.7.5 with Safari 6.1.4. No mcrypt. Went back to 4.2.3 and like someone mentioned previously when I refreshed the login page (after moving back to 4.2.3) I was taken straight to the list of databases (didn't have to log in). If mcrypt is required and it requires PHP to be compiled with it enabled, then it isn't going to happen on this system. I use the stock PHP for this OS (PHP 5.3.28 with Suhosin-Patch (cli) (built: Jan 23 2014 20:55:45)) rather than using something like MAMP or XAMPP.
@Darrik Spaude: in 4.2.3, aren't you seeing the warning about the missing mcrypt extension?
Yes, I see the message "The mcrypt extension is missing. Please check your PHP configuration." However, PMA 4.2.3 still works. The machine is used for local development and is not a live server. The PHP configuration doesn't mention mcrypt anywhere, so it isn't compiled in as an option and I don't intend to spend days trying to build PHP with mcrypt just for a development system (nothing else "requires" mcrypt).
Should be fixed in git, it would be great if somebody could verify the fix.