I am having a problem with the session with the web development framework Kohana 3.2 that apparently is a bug that, at most, can be workarounded. It reports SESSION_EXCEPTION [ 1 ]: ERROR READING SESSION DATA.
My Kohana application isn't in the root folder and I wonder if that has something to do with it.
I have tryed several possible solutions but none of them have worked. Here are some of them:
1) using one library (Facebook SDK), session was initialized on it's own, and session handling was done using the $_SESSION variable. So there were two cookies - session (Kohanas session id) and PHPSESSID. *=> There is only one "session" and "PHPSESSID" variables in $_COOKIE*
2) Workaround or solution was setting in php.ini session.auto_start = 0. => I am working in a shared server (iPage) and I am pretty sure I can't edit the php.ini file.
3) some user's session files were trying to get saved to a directory that didn't exist. So he changed the session.save_path to a valid path and that fixed it. => If he was talking about this php native function , I've created a directory and set it calling this function as the session folder. It didn't work as well. However, I got unsure if I did it correctly (the path "/" would be the root, and not where kohana is in, right?)
4) Apparently this bug is reported to kohana here but I wasn't able to act from reading it.
Is somebody out there able to help me? Thanks in advance.
After researching very much about it and upgradion to KOHANA 3.3, I came to the conclusion that this error was caused when the native function session_start() was called in the Kohana_Session_Native class. It was caused because PHP was trying to save the session in an unavaiable directory. Thus, i just changed this path in php.ini and everything was solved. You may also just call the function session_save_path('YOUR_PATH') in the application/bootstrap.php.
in my case, i run "chmod 777 -R /path/to/session" command and the error has disappeared.
Related
for some reason that I can't figure out my Laravel install has started created a new session file on every request! This renders the session useless and so I users can't stay logged in, csrf tokens don't match etc.
I'm using Laravel 5.2. It seems fine on my local environment but not on the live server
Does anyone have any clues on why this might have happened and how I can resolve it?
Thanks in advance
Locally everything worked, but not on the production server. The problem was in the php.ini settings on the hosting, by default the parameter (variable) "mbstring.func_overload = 2" was set there. I removed it and than all worked. This parameter is for previous versions (PHP) which is used by many CMS. And Laravel gave an error 419 during authorization and nothing more, and created a new session every time the page was updated.
after the upgrade from 5.1 to laravel 5.4 I had a similar issue,
I found that I didn't upgraded app/Http/Kernel.php correctly.
\Illuminate\Session\Middleware\StartSession::class
was declared twice in protected $middleware array
and in
protected $middlewareGroups
after removing it from $middleware array
it started to work correctly
$middleware applied to all routes
and $middlewareGroups applied to specific groups
Check this issue - there's a change in Laravel 5.2.27 that automatically registers the web middleware for you, so if you manually use it in your routes (which you had to in 5.2) then it breaks.
This seems to be quirk of PHP + MacOS. It was a blank line before <?php in our index file. Absolutely ridiculous issue with hours lost on debugging.
My problem was that I was testing locally on the subdomain of the production site.
My local Laravel was at dev.example.com (mapped to localhost), and prod was at example.com. Prod cookies interfered with the development site.
Solution: clear interfering cookies OR move dev site away from subdomain.
have you checked this thread laravel forum
its says to check if there is any blank line before the <?php tag in the file
app/config/app.php , if any remove the blank line
I have just had this problem and it was caused by using dump().
This was sending output to the browser (just as whitespace before php tags would) and causing my session to break.
As others have mentioned, this happens a lot when a session can't start because headers have already been sent to the browser (The session_start function needs to send out several HTTP headers).
It can be due to a space or newline character before an opening <?php tag in any file.
Instead of searching for the culprit, this can be easily solved by enabling PHP's output buffering.
Look for the output_buffering directive in your php.ini and change it to
output_buffering=4096
This is the recommended value for production servers anyway and it may already be defined in OP's local env so the session works there as expected.
I'm trying to get a file's content into a variable but I don't get anything when I read the file. I used both methods JFile::read() and file_get_contents() but both return the same thing: a blank string, not an error , not any boolean values or anything.
I want to mention that I'm working on a Linux machine (just for 2 days) and recently I changed the permissions for the entire machine to 777 ( I don't know if this affects something or not).
Is the a connection between my OS, permissions and the php's file_get_contents()? or Joomla restricts file reading?
Also I want to mention that my file_get_contents() function was added manually by me in the index.php file , also the file I want to read was manually added in the same folder with index.php.
We had the same problem with one of our clients, it turned out it was a firewall issue. It was very hard to debug this issue. I suggest you check with your networking team.
I am assuming, of course, that you have set the PHP error reporting level to the maximum and that you have checked the error logs.
It seemed the problem was from my system . I messed it up when I changed the permissions so I have to re-install it.
Never change the permissions on a Linux for the entire file system.
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
I am using the Kohana 3 framework, and am using the native session driver.
For some reason, occasionally the sessions fail to write to their file.
Warning: session_start() [function.session-start]: open(/tmp/sess_*****, O_RDWR) failed: Permission denied (13) in /home/site/public_html/system/classes/kohana/session/native.php on line 27
I am pretty sure Kohana has its own in built error handler, but it is not triggered with this error (i.e. it shows up like a normal PHP error, not the Kohana error).
(source: alexanderdickson.com)
Anyone that has ever used Kohana will notice this seems to have bypassed Kohana's error handling (perhaps set with set_error_handler()).
Is there anyway to stop this error from appearing without switching from the native session (i.e. file based) driver?
Should I just give good practice the boot and prepend an # error suppressor to session_start() in the core code of Kohana? Should I relax the error_reporting()?
Thanks
You call ini_set('session.save_path', APPPATH.'sessions') (replace APPPATH.'sessions' with the directory you want) in bootstrap.php to force sessions to be written to application/sessions. This will increase the security of using native sessions and should solve your issue.
It's up to php's session.save_path directive, you can override it to some writable folder in php.ini, or you can try this in your .htaccess;
php_value session.save_path '/path/to/folder/you/can/write'
Edit: just so I don't forget, put your custom session folder level below the htdocs/public_html/whatever.
Although, all this is a little overkill since you can ask your server admin politely to check what's the problem with permissions.
This means your php interpreter has no write permissions in /tmp.
Ask your server administrator to fix that - it's unrelated to your app.
In case there are collisions with session files from different php processes (running under different users): Giving them different session temp dirs would help.
For example, you could move them away from /tmp to /path/to/homedir/phptmp and use a structure like that:
/path/to/homedir/
/path/to/homedir/htdocs
/path/to/homedir/phptmp
/path/to/homedir/logs
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.