Greetings.
I am right now in the middle of reinstalling my whole dedicated server. I went with
-Ubuntu Server 10.10
-PHP 5.3.3.1
-php-fpm
-nginx
Now, almost everything seems to work, though there remains one problem with the sessions. No matter what I do, the sessions doesn't seem to store themselves properly (and they did on the previous setup).
The base application is phpBB board. When I login, it's okay - though it appends additional SID parameter to all of the URLs.
forum/index.php?sid=f506ccd42065322f61cb56fc6df6557a
You can navigate around the forums without problem, though if you delete the SID parameter, you get logged out. I thought, that perhaps the sessions aren't stored in cookies, but in URLs, but php configuration seems fine.
The same occurs with phpMyAdmin - I also get logged out, when I delete the token parameter.
In the meantime, it seems the cookies are getting created anyway, it's like they aren't used, or are getting deleted immediately.
I am getting more and more frustrated with that, maybe someone has an idea on how to troubleshoot that? I will post any configuration files necessary.
I thought maybe it's the problem with suhosin (it wasn't installed on the previous setup), but I have no clue. The PHP config is out-of-the box atm, I only modified nginx config.
The various session cookie parameters are all documented here.
In particular, check the "session.use_cookies", "session.use_only_cookies", and "session.trans_sid" settings. If PHP can't succesfully create a cookie, it'll fall back to the trans_sid method (which is what you're seeeing: the session ID being passed around as a query/form variable).
You can trivially check if any cookie-related headers are going out by using Firebug and HTTPFox in Firefox. Both let you view the incoming/outgoing headers for requests.
May be some usefull information can be found in PHP-fpm error log? Set parameters in php.ini
error_reporting = E_ALL & ~E_DEPRECATED
log_errors = On
error_log = ;
some file php can write in or "syslog"
Also try to look in nginx error log.
Does PHP-fpm process-owner has write permissions to sessions dir? See session.save_path on php.ini for session dir
See if your session_path is correct and has the right permissions. That fixed my problem.
Also, be mindful of the user and group of the processes, as this will effect the default permissions that the session files are created with. If set to default, it may create as root, and then not be able to be read the next time the session file is accessed.
Look for Unix user/group of processes in your php-fpm.conf
and set both user and group to php-fpm
Related
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)
I've set up a new server for my magentocommerce.
Unfortunatly when I moved the domain to the new location (tests have been done using another domain) a weird issue started happening: when the login page displays on the frontend, or the backend and I (and customers, of course) do submit the right credentials the page refresh, the cookie gets set but the form is displayed again. It's such a cache being served instead of the right content (catalog).
The only solution actually is delete the cache on the browser and retry.
I've used varnish http accelerator for two days, but since I've had too much issues dealing with it I uninstalled it and cleaned things up (now there's only the apache instance to serve user requests).
I also installed APC caching and Fooman Speedster.
What can it be to cause this issue?
Can you please help me to get in the right direction to fix this issue? On the old server it was not happening, but since that time there have been some modification to the store (nothing to do with authentication anyway).
The apache error log does not report anything, the only thing in there is PHP: syntax error, unexpected BOOL_TRUE in /etc/php5/apache2/conf.d/apc.ini on line 4 which has to do with the line apc.enabled = 1.
Look at the System -> Configuration -> Web tab in the admin panel and see if the Cookie Path and Cookie Domain are set correctly for the new server. You can do it directly in the database as well. In this case, search for rows with web/cookie/cookie_path and web/cookie/cookie_domain paths. Setting them to empty values in the admin panel or NULL in the database may also help.
You should also clear Magento cache (System -> Cache Management) and APC cache (here's how to do it: How to clear APC cache entries?).
I don't know if it solves your specific form problem but we had the same error in the apache error log.
Our failure was, we've copied the apc.ini code from http://magebase.com/magento-tutorials/speeding-up-magento-with-apc-or-memcached/. They use "#" for comments.
Turns out we had to use ";" for comments. After these changes, there were no more errors in the apache error log.
My Problem is quickly described by the need to extend the session data life over it's default settings within the php.ini without changing the php.ini. I am looking for a solution that can be applied to a number of different php setups across server platforms so there is no need for the script to be changed for every install.
Since I don't want to change defaults on my server and want to stay as independent as possible with my script I am looking for a way to exceed the default 1440 seconds that are set for the garbage collector to dispose of my session data prematurely.
Simply setting ini_set('session.gc_maxlifetime',36000);
to 10 hours will not work as on some servers the GC will run unaffected by php's settings and delete my sessions after 24min anyway as described here.
To get around this problem the author suggests to change the session.save_path to another folder unaffected by the os's gc and thereby enforcing the set session.gc_maxlifetime to my settings.
Unfortunately I was unable to create a temp folder within php's tmp space and though I like to I don't seem to be able to since I don't have 0600 access on most servers.
One solution would be to link my session data to my own folder created right in my shared host folder but that seems insecure as this folder must then be available online and therefor exposed to possible id theft.
Though I do not know whether that is the case.
Another solution would be to include $_SESSION["stayalaive"]=time(); since the gc only deletes sessions untouched for the specific amount of time to the login script so that the session will be extended every time the login script is called though that means if the user does not click anything for 24min the session will be deleted anyway which is something I could possibly live with but it also seems to put on another process that seems unnecessary.
So my question is how to set up my session data to stay alive for 10 hours without clocking too much performance for it.
I have used php.ini directives inside scripts before and besides you can make directories inside your hosting reserved space.
So (at the very beginning of your script) this must be work, no doubt:
<?php
// obtain current directory
$APPPATH = dirname(__FILE__);
if ( ! file_exists($APPPATH . '/tmp/sessions'))
{
mkdir($APPPATH . '/tmp/sessions', 0700, TRUE);
}
ini_set('session.save_path', $APPPATH . '/tmp/sessions');
ini_set('session.gc_maxlifetime', 36000);
session_start();
?>
Both directives have PHP_INI_ALL changeable mode, so can be set inside scripts.
Any webhost worth their salt will give you a directory above your public_html (or whatever) folder. If yours does, then you can create a directory for sessions there, and it won't be accessible from the web.
If your hosting is so crappy that anything you're allowed to touch via FTP/SSH/whatever is also available via HTTP, things are more annoying.
So assuming you have a crappy host, here are a few ideas:
1) Store sessions inside your web root, and use .htaccess to make it non-browsable.
2) Store session data in the database.
Either of those options should enable you to set your own garbage-collection rules via ini-set(), and avoid having other processes clobber your sessions.
I have a problem where i am losing the PHP session between 2 pages.
The session_start() is included in a file called session-inc.php into every page requiring a session to be set. This works for all pages on the site except one particular page, member-profile.php. When this page is visited a new session with a different id (same session name) is set and used instead.
A few more details:
Session name is set manually
All pages are on the same server under the same domain name
If i put an additional session_start() above the include('session-inc.php') in the member-profile.php file, the session is carried over correctly
I have tried setting the session_cookie_domain and session.session_name in the .htaccess, this worked for this domain but it stopped the session being passed over to out payment domain
We are running apache 2.2.6 with php 5.2.5
Putting the session_start() above the include('session-inc.php') in the member-profile.php file is the quick and dirty fix for this problem, but i am wondering if anybody know why this would be happening.
Cheers
Will
According to PHP documentation, session_start must be called before any output is sent back to the browser-- could this page have a rogue CR/LF, Unicode byte-order mark or similar that is causing output before you include('session-inc.php')?
While migrating a legacy site from PHP4 to PHP5 I noticed a php.ini configuration setting that causes php to auto-start the session upon every request. It's an alternative to placing session_start() onto every page...
There are multiple ways to enable this setting:
Put the following line into php.ini:
session.auto_start = on
or put this into your apache virtual-site config or .htaccess file:
<IfModule mod_php5.c>
php_flag session.auto_start on
</IfModule>
and it should make $_SESSION changes available across all pages
I have just encountered this problem. Interestingly, browsing via http://127.0.0.1 instead of http://localhost helped me.
I just spent all day diagnosing this issue in my Ionic3 - to - PHP project. TL; DR - make sure your client is actually sending session credentials.
In the interest of helping anyone who makes this mistake, I will share how I found the problem.
I used these tools to diagnose the session on both the client and server:
1) Add a test file with phpinfo() to the server to review PHP session options.
2) Review the PHP code to make sure that no output, intentional or un-intentional occurs before the session_start() line. Check the status bar of Visual Studio Code to make sure the Byte Order Mark (BOM) is absent from the PHP files.
3) Review server PHP logs (in /var/log/nginx/error.log for me). Add error_log() lines to the php file to dump the session_id() or $_SESSION array.
4) Use tcpdump -An 'port 80 or port 443' to view the actual HTTP requests and replies. (That's where I discovered the missing cookies).
For an Ionic3 data provider the correct syntax for the client is:
var obsHttp = this.http.post(url, body,
{ headers: new HttpHeaders({
'Content-Type':'application/x-www-form-urlencoded'
}),withCredentials: true }).timeout(this.timeoutTime);
Notice the withCrentials:true
One needs to call subscribe on the obsHttp() observable to send the request.
Found the issue
There was a byte order mark at the beginning of the main includes file of the second domain. as stated by ken, cant have any output before a session start, it was not setting the session correctly.
SOLUTION:
session.auto_start = on
in file: php.ini
It solved the issue of re-generating session id on page reload (page refresh / change pages).
The issue appeared after the update of CPanel (and included Multi PHP), even the php version remained the same.
The PHP.ini file didn't had that variable at all.
Went in Cpanel -> MultiPHP INI Editor -> Editor Mode (not Basic, in basic you do not have this setting) and added the line. Press Save.
TIPS / WHEN TO USE THIS SOLUTION:
To determine if that is the problem, put a line at the very beginning and at the very end of your index.php file to check the session id. Use function:
session_id();
Navigate through pages / reload the page. If the session_id value changes the problem is not in your code and this solution should solve your problem (the session is lost outside of your code).
I also tried to verify the availability of saving session on the web server (session.save_path) but, even if it was a lead, it was not the case.
I imagine this is a "feature" of Cpanel with MULTIPHP UPDATE that will happen quite often.
I had this problem, and the cause was that PHP was ignoring all cookies after the first 100. (I asked this question to try to find out why, but so far nobody has figured it out). The browser was sending the PHPSESSID*, but since it was the 110th cookie, PHP was ignoring it.
To figure out if this problem is what's affecting you, use your browser's dev tools to look at the cookies that the browser is sending with the request, and compare that list to the $_COOKIE array in PHP. They should be the same. But if the browser is sending a PHPSESSID*, and there's no PHPSESSID* in $_COOKIE, then that would explain why sessions aren't working.
I solved the problem by not having my site use so many cookies, which is good practice anyway.
*PHPSESSID is the default session name. Your site may use a different name.
To solve the session_id change after each request, you change the parameter session.auto_start and session.cookie_httponly into the php configuration file.
to find the used php configuration file
php -i | grep "php.ini"
then you open it, and try to find the parameter session.auto_start . you set
session.auto_start = 1
session.cookie_httponly = 0
finally you restart your httpd/apache service.
Found the issue
In my case it was due to Varnish Settings please check your varnish settings. PHPSESSID you can exclude the cookie from the Varnish Settings.
I'm not an expert, but found a solution after careful investigation of domain name in the cookies info of two webpages opened on Firefox. (Right click on the page, select inspection and the storage). checked domain names and found that one with www.example.com and the other without www (example.com). changed all the page links to same format and the problem solved for my case.
Found the problem was a byte order mark (BOM) being ouputted at the start of the file. Got rid of it and it sorted out the session problem.