I copied an existing and successfully running site to a new development server.
The login on the new server is now broken, and I tracked it down to the fact that although the session cookie is renamed ...
ini_set('session.name', 'DOMAIN1');
... the browser keeps storing the sesssion cookie as PHPSESSID.
When I remove the above line from the application on the new server, the login works again. But this is not a good solution, because another application also uses PHPSESSID under this name.
And I would prefer to find the reason for the strange behaviour instead of using a workaround. If I don't fix it it could bite me somewhere else.
Maybe this is already enough information for someone to give me a hint. If not, what information would be useful?
This machine was a very naked and basic ubuntu 8.04 server, and I installed apache2, mysql and php5 with aptitude. I also updated lokales and the timezone.
Solution:
I replaced the line above with this code from from the accepted answer ...
if(ini_set('session.name', 'DOMAIN1') === false || !session_name('DOMAIN1'))
{
die('Unable to set sesssion scope');
}
... and the login now works on the new server.
Sometimes ini_set plays up and is unable to set the ini values correctly, might be down to permissions.
the below does not fully resolve the issue with ini_set, and if anyone knows the reason(s) why ini_set does not work on some type's of host, then please share!
Try the following:
<?
if(ini_set('session.name', 'DOMAIN1') === false || !session_name('DOMAIN1'))
{
die('Unable to set sesssion scope');
}
phpinfo();
?>
alternatively you can just use session_name() to set it, and ill always advise you not to just run functions and hope the always check the in an if statement and prepare for the worst case scenario, thats when your application becomes reliable and less error_prone.
Related
I need some help installing Moodle v3.7.2.
I've passed all checks for server configuration during installation, except for the fact that the site is recognized as http instead of https, maybe because of the proxy that sits in front of the nginx serving Moodle. Anyway, when I try to load the first page, I receive a generic error:
$string['servererror'] = 'An error occurred whilst communicating with the server';
I've investigated the source code for this error, and found the motivation:
On path /moodle/lib/classes/session/manager.php, row 90, this check fails:
if (!self::$handler->start())
The start() method is simply calling a php function:
session_start();
That returns FALSE and throw the exception. Any idea on how to solve this? Many thanks.
EDIT: I've also tried storing sessions on database:
$CFG->session_handler_class = '\core\session\database';
$CFG->session_database_acquire_lock_timeout = 120;
But with no luck, now the function that fails is:
session_set_save_handler
I have run into the same issue when installing Moodle 3.8 on a Windows-Subsystem-for-Linux (WSL) based Debian development server. Adding the config to switch to database sessions fixed it for me:
$CFG->session_handler_class = '\core\session\database';
$CFG->session_database_acquire_lock_timeout = 120;
I'm thinking that the WSL permissions are problematic when the Moodle data directory falls outside the moodle vhost path, so Moodle cannot read/write properly to the sessions path (yet I do see session files being created). You must delete the browser cookies/restart your browser after setting sessions to the database.
This is more of a generic solution, but did you check your $CFG->wwwroot in your config.php file? It has to be something like 'https://your.site.com/'. If you forget the s Moodle won't be able to build a connection if you configured your Webserver / proxy to forward users to :443.
I ran in this problem quite often, when I configured SSL for our Moodle Server.
I'm using a private mediawiki hosted on AWS EC2 instance for years
I thought something gone wrong with some extension, specifically stopping in the middle of math rendering, so I tried to reload the page with Google Chrome browser's cache were all erased.
Right after that, I can't log in seeing this message "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."
I tried,
1. restart apache server
2. tried MediaWiki sessions and cookies not working on multi-server behind CloudFlare
3. tried Mediawiki, can't login after password change
4. tried "go in your LocalSettings.php and at the end add the following code of line :session_save_path("tmp");Create a folder "tmp" in your wiki installation directory. give rights 777 (permissions)" as in https://www.mediawiki.org/wiki/Topic:Pjby0sdeg3e60rfy
5. checked the server's hard disk storage, but it has free space of way more than 3.5gb.
How do I fix this and is there any way of disabling this really helpful "PRECAUTION" feature?
Adding $wgSessionCacheType = CACHE_DB; to LocalSettings.php solves the problem. No need to change $wgMainCacheType.
This works, without the "precaution against session hijacking" error:
$wgMainCacheType = CACHE_ACCEL;
$wgSessionCacheType = CACHE_DB;
Turned out to be something went wrong with cache settings in LocalSettings.php. Resolved after removing (almost all) customized cache settings.
MediaWiki authentication and session handling has been rewritten for 1.27; see announcement (the last section). Session hijacking warnings mean the CSRF token you are submitting was not found in the session, which in turn usually means the session storage is configured wrong.
Twice now, we started getting this error after the server ran out of space. Turns out, both times it was because the objectcache table had been corrupted.
To fix it, just run the SQL statement (e.g. at a MySQL prompt):
REPAIR TABLE objectcache;
I'm making use of storing random token values into session as well as flash message which prints out messages for one time only upon registration of updating profile,, this is working so far like it should on the localhost - wampserver. However, after deploying the website to the live server the process works correctly as long as the user is not logged in, after I log in I just can't update the profile at all, also after a successful registration the message "you have been registered successfully" is shown every time I go to the the homepage while it should only appear once and only once.. and again on the local server it is working like charm.
So after checking some online resources the answer was it mostly the configuration of php.ini on the server is what causing the problem, so I checked the php.ini on the server and after comparing it to the local one i found these two line missing concerning the Session field:
session.save_path = "c:/wamp/tmp"
session.use_only_cookies = 1
Then I added them to the online version of php.ini and it still doesn't work, of course I've changed the save_path to some random value but the whole storing in session doesn't work at all until i comment the session.save_path line, the other line didn't change anything so I don't know where the problem is.
Thanks in advance.
you're trying to write to a directory php doesn't have write access to. when you comment out the line, it stores it in the default php save path, which it does have write permissions.
I just found this PHP Based session variable not retaining value. Works on localhost, but not on server and it is exactly the cause of the problem, these people using register_globals ON .. that's it.
I have a DMZ set up with a web server and an application server, both running Ubuntu under gnome (v11.04 on the web server and v11.10 on the application server). session_start() has started hanging on the application server. The code is located on the application server and it does not hang when I access my web site and access the page with the session_start() call on it. It seems that every session_start() has started hanging on the application server although I have no problems with the associated pages when I access them from other computers or across the web. Also I have only just started having this problem on the application server without having made any changes to my php code. Could it be that some buffer has filled up and needs to be cleared?
I tried editing /etc/php5/apache2/php.ini and setting
session.save_path = "/tmp"
/tmp exists.
But I still have the problem. I can stop it hanging by preceding session_start() with session_end() but then it does not execute the remaining PHP or html code in the file.
/var/log/apache2/error.log included the following message:
PHP Notice: A session had already been started - ignoring session_start() in
/var/www/DraculaPgm.php on line 101, referer:
http://MyWebSite.com/ApplicationServer/Dracula.php
Any assistance with this would be greatly appreciated,
Peter.
Update 29-Dec-2012
Thank you to everyone who replied to this question. Unfortunately, I tried all of the suggestions and 'session_start()' still hangs. However, if I leave it for a few minutes, it breaks with the following error message.
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /ApplicationServer/Dracula.php.
Reason: Error reading from remote server
Apache/2.2.17 (Ubuntu) Server at MyWebSite.com Port 80
I have squid installed on the web server. Could this be a problem?
Thanks,
Peter
This sounds like a configuration issue. Make sure that PHP is reporting all errors, i.e., error_reporting(E_ALL) and either display or log all errors. (You might even want to enable display_startup_errors in your php.ini) - reporting all errors may shed light on what's going on. (if you need help you can post any errors that you get from this as an edit) You may want to look at the following as well for troubleshooting the issues with sessions:
When using /dev/random as session entropy file
When page is calling itself with the same session
Alternatively if none of those show anything you may want to read over the bug report at https://bugs.php.net/bug.php?id=28856&edit=1 depending on what version of PHP you are running.
I changed 'session_start()' to the following block.
if(!isset($_SESSION))
{
session_destroy();
session_start();
}
I now do not have the problem. I am hesitant to say that it fixed the problem since it did not seem to fix it right away.
Thank you to everyone for your help,
Peter.
Try changing the permission of the /tmp folder by doing chmod 777 /tmp and check if its working.If its working then change the permission mode to make it more secure
Try checking out this Question I call session_start() the script hangs and nothing happens
And this http://www.projectpier.org/node/1934
"It seems that the session file is opened exclusively. On some
occasions (Windows) I have found that the file lock is not released
properly for whatever reason, therefore causing session_start() to
hang infinitely on any future script executions. My way round this
problem was to use session_set_save_handler() and make sure the write
function used fopen($file, 'w') instead of fopen($file, 'x')"
You can find many others having the same problem and their workarounds if you go through http://php.net/manual/en/function.session-start.php
if(!isset($_SESSION))
{
session_start();
}
Use this at the top of your PHP file!
And for your info: session_destroy() is used to end session.
Before anything else - try another browser!
I just encountered this session_start problem. I checked my tmp folder and everything and I was about to call my hosting-provider until I thought I should try another browser first because it might have to do with session cookies.
I work with chrome, so I tested in IE and found that it was indeed the case: It worked in another browser!
I closed IE ;) - went back to chrome, looked for the cookie (PHP_SESS_ID), deleted it and everything works again!
Well, the good part is - Just like you guys I got to brush up my knowledge of -jay- sessions! ;)
i having a strange issue in sessions.. this is working in WAMP server in my local machine.. my problem is wen hosted to a server in US it's not working..
im doing like this:
session_start();
$_SESSION['test'] = 'testing login..';
in another page i'm doing:
session_start();
echo('my session value is : '.$_SESSION['test']);
but i'm getting only
my session value is :
my session value is not setting..
i checked the session.save_path in cPanel of the server it says /tmp.
pls help..
thanks in advance.
Maybe your script dies because session_start fails with "headers already sent" ? This could happen, for example, if your test machine and production server don't encode new lines the same way...
The errors are probably not displayed on your production server, try something like that :
ini_set('display_errors', 1);
session_start();
and see if you get something useful.
The php opening tag must be written at first line of a php file. This method help me to solve this problem.
Check the permissions on your session.save_path. This location will need to be writable by the Apache/httpd user.
Also check to see if you session.save_path contains any sess_ prefixed files.
thanks for all the help.
my issue was security permission in /tmp folder. once it rectified it's working.
mean time dont use only numeric for SESSION ids, (Eg. $_SESSION['12345']) because in linux hosting its not taking the numeric only index and skipping that. (so use $_SESSION['ACS12345'])..
Take a look at the way you created the file.
If you used auto language detection features, or something similar to create your file, then try creating a new PHP file. Copy your code and try again.
if you're using siteground as your hosting you will need to enable the auto session. follow this steps
Navigate to Dev
click on php manager
click on php variables
Load more until you find session.auto_start
Turn it to yes and you're good to go