I am using xampp on chrome in a mac and I can't access phpMyAdmin. I used to get a error on the site, but I changed the session.save_path in the configuration file and it opened put now every time I try to press something it gives me an error saying Error: Token mismatch.
Here is the error I am getting:
Here's a link of the same image: http://ninjas.zxq.net/error
Does anybody know why this is happening?
I found the answer.
Go to your php.ini file in Applications>XAMPP>xamppfiles>etc>php.ini
around line 1507 uncomment the line
;session.save_path = "/tmp"
by removing the semicolon. This worked for me right away.
simply changing the tmp path wasn't enough for me..
verify in your browser that you accept cookies and that adblock etc.. is disabled.
although having said that if you've managed to post to this site all that is probably under control :)
I had the same issue, except none of the answers solved my problem. (Localhost with Xampp on Windows 10, using Chrome.)
After some time I figured out that you have to manually delete browser cookies etc to let it refresh/reset the token.
My problem solution was something different again.
I had a user script that was active on the page. In my case it was a TamperMonkey script, but GreaseMonkey, ViolentMonkey, etc could do the same thing.
As soon as I disabled TamperMonkey, problem solved.
First I disabled TamperMonkey completely, using the Enable/Disable checkbox on the icon, to test the theory in general. Problem went away. So then I identified the specific script that was active on the phpMyAdmin page, and I was able to just disable that one script to solve the problem.
Note that the problem script did not in any way modify the phpMyAdmin page - I reduced it to a literally empty script that was loaded onto every webpage. However, just loading itself (an empty, do-nothing script) onto the phpMyAdmin page enough to cause the problem.
Find your php.ini (php -i|grep php.ini) if nginx edit /etc/php5/fpm/php.ini if fpm used.
Uncomment ;session.save_path ="/tmp"
Restart apache or if you use nginx - /etc/init.d/php5-fpm restart
Check /tmp directory to make sure sessions are getting saved there. if you see something like "sess_h820h8ja6pl4bhdmqflngeui23" then your are done.
Related
I was having problems with my PHP website (SuiteCRM) not being able to log users in and I found it was due to not being able to write on the sessions directory.
I am able to fix it by creating the directory /tmp/php_sessions and giving it write permissions for the Apache user www-data. I see the directory get populated with files as users log in.
However, Ubuntu Xenial is deleting my entire tmp directory on reboots, so I have to redo this all over again every time. I decided to move my save_path elsewhere.
After changing things in my php.ini file, and restarting Apache, I can check that they are effective by running this simple script:
<?php
echo ini_get("session.save_path");
phpinfo();
?>
This shows me a double confirmation of the new path, first echoing /var/tmp/php_sessions and then, in the middle of all the phpinfo information, showing the same value as both Local Value and Master value for directive session.save_path.
BUT the directory that php is using is still the first one, /tmp/php_sessions! It seems that my setting is being ignored.
Am I overlooking something? Where could that old setting be buried? Or how can I make the new one effective?
(P.S. - I am not using a redis handler as in another similar SO question)
Ok, I solved my own problem and the general answer is as follows:
There are two more things that can be changing the path and need to be checked,
the PHP code of the application might be changing the ini directive, search the code for ini_set(session.save_path
the PHP code might be using the session_save_path PHP command to override the ini. Search the code for that also (and notice the two underscores _!)
And the specific answer for my case was that SuiteCRM uses session_save_path command to set its path with a value coming from the file config.php found at the web root. That's where I found the old setting, and changing it solved my problem (for good, I hope).
I have a weird problem I cannot seem to solve (as a php noob).
I am working on simple php site (no sql involved). Everything was working perfectly till the moment I decided to copy over the files and edit them on another computer. All worked fine on the other computer as well. Then I took the files and copied them to the first computer again. Here came the problem: if I try to open ANY file copied from the second computer, it doesn't show anything, just a blank page. Even if the file was not edited at all on the second computer.
For example my index.php:
1. Copied from comp 1 to comp 2, no edits done
2. Copied from comp 2 to comp 1
3. Opened in the browser -> blank page
What's going on here and how to solve it? Is it some cache that apache is keeping? How to clear it? Both computers with OSX, however the second one was running MAMP, while the first had php/apache/sql set up.
Your permissions need to be set up correctly. Do the following:
Change the owner of the group to your user
chmod 0755 all the directories
chmod 0644 all the files
Then you are good to go!
You need to make sure that your permissions are set up correctly.
Apache Permissions
The blank page is displaying because Apache is encountering a PHP error somewhere, but is not set to display PHP errors.
Check out what is going on in your Apache error log and work from there. You could also look in the Developer Tools of a browser like Chrome, or use Firebug, to see what response your browser is getting from the server (most likely a HTTP 500 error).
I wouldn't recommend blindly changing ownership on files and directories until you know what is going on.
I have phpMyAdmin on a remote server. It was fine until today, I used it many times (so the username and password are fine). However, today the whole site did not worked, it simply said "too many connections".
First I retried to restart Apache and MySQL, and it didn't fixed the problem.
Then I rebooted it with shutdown -r now, and the main site does work now, but phpMyAdmin still won't log in (and it does not show any error). After typing my user and password and hitting enter, it shows the exact page (with no error) as nothing would have happened. I can see that the token is different in the Address bar though.
I tried removing all php sessions manually from /tmp folder (by ftp), and it has the same problem. Could the database of phpMyAdmin itself be corrupt? How can I fix this?
Thanks in advance
My issue was, I was using HTTP instead of HTTPS. I don't know why, my server allows both connections, but I must have made a change some where so it only allows HTTPS connections. Once I switched over, the website started to work again.
In my case, the hard drive on the server was full.
In Linux, use df -h to view the available space on the hard drive and clean up unnecessary files.
I just spend forever troubleshooting this.
You are missing the mcrypt extension.
The mcrypt extension is missing. Please check your PHP configuration
You can check if this is the case by forcing
$cfg['Servers'][$i]['auth_type'] = 'http';
and looking at errors when you login.
Possibly no space left on the device. In many cases it will not allow to create the session due to lack of space for the file.
Possible reasons are-
a) user has been locked.
b) There are too many users more than specified.
c) Your System/Ip (rights were provided to which) has been changed.
Please follow below steps-
Step1: Please server connect with root user and check if you are able to use your DB.
Step2: execute below commands.
mysql> flush hosts;
Now try to connect from phpmyadmin if success then fine other wise check if you are getting any IP related error if yes then check if that ip have required permissions.
Other Reasons may be
opened_files_limit crossed whatever you mentioned in your configuration file.
disk full.
too many thread opened/too many connections.
your login_user has been locked due to wrong password input a certain times (limit mentioned in configuration file default is 10).
mysql port (default is 3306) is not open on DB server from outside.
user does not have permissions from your system IP. etc.
In my case, it was that I was trying to access through HTTP, not HTTPS.
Once I changed the address to https://mysite/phpmyadmin I was able to access.
I had similar problems with login. I solved it by clearing browsing data in Chrome. Maybe just simple restarting Chrome would be enough. I noticed that I was able to login in incognito mode even without clearing browsing data or restarting Chrome.
Interesting when I was trying clearing cookies for site manually it didn't solve the problem.
Check if there is enough space available on server. In my case it was space problem. I deleted some files and its working fine now.
To check available space : df -h
To check available inodes : df -i
CodeIgniter cache was taking so much space.
If there are multiple MYSQL connection running simultaneously, PHPMYADMIN won't allow you to login (neither it'll show any error).
Either you need to increase your max_user_connection value (you can do that via ini) or you need to wait for sometime and try.
Had the same issue.
I made a typo in my php.ini file (letter 'B' at the end of 2GB is the error):
post_max_size = 2GB
upload_max_filesize = 2GB
Apache started up but the php.ini file didn't load correctly. After fixing the typos and reloading Apache every thing worked ok.
Another reason not mentioned so far:
Modifying the webserver headers such as X-Frame-Options and others can have an effect on loading any page post-login. After login, you may see the login page refresh, but notice the address bar shows index.php+hash (meaning you are actually logged in). Or, you may simply get a blank page.
Use a browser inspector to check your PMA login page for headers received - if you see something, check your webserver configuration files for header modifications. In my case X-Frame-Options was set along with others. Once I commented these out, PMA was fine..
sudo htpasswd /etc/phpmyadmin/htpasswd.setup admin
a redirect can cause error.
for example this lines in .htaccess in root folder :
# redirect all index.php to the folder root
RewriteCond %{THE_REQUEST} ^.*/index\.php
RewriteRule ^(.*)index.php$ /$1 [R=301,L]
to solve it , you can simply create a .htaccess in PMA directory and put this line in it :
RewriteEngine Off
My issue was a hard coded host ip in the config file:
$cfg['Servers'][$i]['host']
Since my host IP has changed, I started having the issue.
Hope this helps someone else.
This is just a work around but it works for me. When trying to connect to phpMyAdmin use the local host IP address instead of the word 'localhost'.
For example type '127.0.0.1/phpMyAdmin'
The problem I am having is that I can not log on to my newly created wiki that I made using MediaWiki. I have searched the web for an answer, and the ones I found did not help with this specific issue (like this one: problem with mediawiki cookies) I have tried with multiple browsers and changed the setting to make sure that cookies are enabled, but I keep getting the same error:
"Wiki uses cookies to log in users. You have cookies disabled. Please enable them and try again."
I'm not sure whether this is a problem with my current version of PHP, which is currently 5.3, or a setting in my wiki.
I found a fix, I'll put it in steps:
Open LocalSettings.php
Go to the bottom of the page, and enter in the following code: session_save_path("tmp");
Create a directory called tmp in the folder where you have MediaWiki installed.
If you are using NGINX + PHP-FPM the previous answers will likely not solve your problem.
From my experience, this issue is caused when php-fpm doesn't have write access to the cookie_path. You can find this path by running:
php-fpm -i|grep --color cookie_path
See what your cookie_path is, then stat the folder and ensure your php-fpm user has write access to it.
To resolve this issue using Nginx and Php-Fpm, I had to change my cookie_path from it's default of / (seriously, why would this be a default?) to /tmp.
After restarting nginx and php-fpm, it works perfectly.
The easiest solution, also recommended by Aaron Schulz, is generally to set
$wgSessionsInObjectCache = true;
$wgMainCacheType = CACHE_ANYTHING;
in your LocalSettings.php. In recent PHP you'll have OPcache enabled by default; if no accelerator is available, at worst this configuration will use the database.
See also cache documentation.
I also had this issue ...
All my browsers were complaining about cookies being turned off....
I thouhgt a group policy had been implemented to disable cookies.
After conferring with my server support team that nothing as such had been implemented I decided to remote to the server.
The server was complaining about low disk space.
I cleaned up the disk by deleting some old unrelated files.
Tried to logon again from my browser and all was Ok.
One answer which hasn't been mentioned here - make sure your file system isn't out of space.
same thing may happen when memcached is used to store session files. in this case wiki will be unable to write cookies neither in / neither in /tmp. if you see in error.log something like
"file not found (11211:9001/qweqweqweqweqe)" this will mean, that you have memchached installed and configured and you need to append the following lines in LocalSettings.php:
$wgMainCacheType = CACHE_MEMCACHED;
$wgParserCacheType = CACHE_MEMCACHED; # optional
$wgMessageCacheType = CACHE_MEMCACHED; # optional
$wgMemCachedServers = array( "127.0.0.1:11211" );
$wgSessionsInMemcached = true; # optional
Just ran into this issue on a Win2008 R2 server running IIS,
when creating a user gave this (red) msg:
Account creation error The user account was not created, as we could
not confirm its source. Ensure you have cookies enabled, reload this
page and try again.
Also if a user tried to log into the Wiki, they would get this (red) msg:
Login error (WikiName) uses cookies to log in users. You have cookies
disabled. Please enable them and try again.
Failed attempts:
I tried JesseG17's solution, but could not save changes to the
localsettings.php file (despite stopping the server).
I checked permissions on the temp location, but that didn't help.
I changed tried changing the temp location via IIS's PHP manager, but
that didn't change anything.
What finally did work was to use IIS's PHP manager to change the
MediaWiki's PHP settings; session.use_cookies from 0 to 1
This solved the problem without any reboot.
Be root:
su -
Then edit the php.ini file:
nano /etc/php5/apache2/php.ini
And set those variables to /tmp:
session.save_path = "/tmp"
session.cookie_path = "/tmp"
You can also correct the permissions just in case:
chmod -R 1777 /tmp
I'm adding a new answer because my setup was slightly different, and the steps I took were similar but not identical to everyone else's.
I installed MediaWiki on CentOS with NGINX. After running it successfully for a few months, I started to get the same cookie error out of nowhere.
The issue I had was that the php-fpm user lacked access to the session.save_path folder. I don't know why it happened, but here's now I fixed it.
I ran a variation of SprintCycle's command to identify where the sessions were stored:
php-fpm -i|grep --color save_path
In my case, it was /var/lib/php/session.
Then I changed directories and set permissions:
cd /var/lib/php
chmod -R 1777 session
I restarted the services, and everything worked again.
service nginx restart
service php-fpm restart
Another thing to check is if your session tmp directory is full. Symptoms are "write failed" messages in your http server error log. Duh!
I had to uncomment the wgCookieSecure setting in LocalSettings.php:
#$wgCookieSecure=true;
only found this after having checked that another wiki on the same computer ran just fine with similar settings. So to debug you might want to install a fresh mediawiki in a neighbour directory and check whether that gives you any trouble. Then you can go thru all the suggestions here as well as the one at
https://www.mediawiki.org/wiki/Topic:Rg3w5u0e70fs8l4e
Put
$wgDisableCookieCheck = true;
in your LocalSettings.php.
(source)
We're building a new server and using IIS 7. PHP pages a served just fine and dandy, but the second we use any code to access a MySQL database, the page hangs for a good minute and serves the following error:
Server Error
500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.
Our database.php config file is configured correctly, so I can't figure out what might be doing this. MySQL seems to be properly installed as well.
Any ideas? Googling hasn't lead me anywhere useful.
Looks like your MySQL-Extension of PHP is not loaded correctly. Is it included in the php.ini? If so, please just take a look in the php_error.log. There should be an entry there. Please post it here
Rdp to your IIS web server
Right click on the folder where your site contents in and click on properties
go to security tab > advance > click on Edit > click on add > and enter domain users and click ok.
Now click on Edit and give full control or modify or read
Now select "Replace all existing inheritable permissions on all descendants with inheritable permission from this object
Click on apply, let it finish the process and click on Ok and ok.
This will fix the problem.
Change the memory_limit variable in you php.ini file. I had a similar problem where I was doing a very large select query.
On a development server the query would run fine, but on the live server it would throw a 500 error.
The difference turned out to be that my live server's memory_limit was set at "64M" whereas the dev server was "512M". I bumped the live server up to 512M and that resolved the problem.