cannot send session cookie

[jaco]

Hi, I am just recently getting this error message:Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /home/XXX/chordsandguitar.com/index.php:46) in /home/jchords/chordsandguitar.com/index.php on line 48

 

this is no doubt related to the fact that my site has been hacked along with 1000's of others that are on dreamhost. I don't know if it's related to php file permissions some of my files may have had had their permission set for read-write when they should not have been. They have all been changed to the more restrictive 755 or 644.

 

So here is how I am using the session_start to store some variables:

 

session_start();

if (!isset($_SESSION["count"]))
{
$_SESSION["count"]=0;
}
else
$_SESSION["count"]++;

if ($_SESSION["count"] == 0)
{
$scale_menu = 'C';
$variation_menu = 'maj';
$code_id = '1';
}
else
{
//allows retreiving the value of the drop-downs after the Select button has been pushed
// has to be skipped on the first access or overwrites starting vars. to null
			 if (isset($_GET['s_menu']))
	 $scale_menu = $_GET['s_menu'];
	 else
	 $scale_menu = $_GET['scale_menu'];	
}	 

 

So any ideas why I am getting this error?

 

Thanks,

 

Jacques

[trq]

You must have missed this: http://www.phpfreaks.com/forums/index.php?topic=37442.0

[scootstah]

Post all of the code.

[billkirim]

write this line on your .htaccess file

 

PHP_FLAG output_buffering on

[scootstah]

write this line on your .htaccess file

 

PHP_FLAG output_buffering on

 

That is a band-aid at best. It doesn't fix the error, it just masks it.

[billkirim]

i will disagree with you But if you want an alternative solution use

ob_start();

after the session start();

 

and

ob_end_flush();

at the last line of your code..

 

it does has the same results..

 

[billkirim]

sorry for my spelling mistakes

[trq]

i will disagree with you But if you want an alternative solution use

ob_start();

after the session start();

 

and

ob_end_flush();

at the last line of your code..

 

it does has the same results..

 

 

More band aids. It is logically incorrect to try and output something before sending headers. The code should actually be fixed.

[scootstah]

i will disagree with you But if you want an alternative solution use

ob_start();

after the session start();

 

and

ob_end_flush();

at the last line of your code..

 

it does has the same results..

 

 

You can disagree all you want, that doesn't make it any more correct.

 

It's the same thing as slapping @ on everything. Sure it makes the error go away, but the code is still wrong.

[billkirim]

i disagree that it masks the error.. i agree that is incorrent to try and ouput something before sending headers.

 

with output buffering on Flag, the output is collected and then flushed to the output stream.

 

As thrope said "It is logically incorrect to try and output something before sending headers."

 

i read that the site has been hacked and changed only permissions so i thought that the source has not been affected.

 

Anyway i post some thoughts just to help..   

Thanks

[scootstah]

The error is because output was sent before a header call, which is logically wrong. Using output buffering means that any output is not output until the end or until you tell it to be output, thereby not outputting anything before headers, thereby masking incorrect code.

[PFMaBiSmAd]

Since the problem started after someone gained unauthorized access to the files on the server, why would using/turning on output_buffering be a correct solution? The only ways code could have gone from not producing a header error to producing one is if the code in the file got altered or if output_buffering was previously turned on/being used and now it is not. The file could have been altered and is now outputting spam content or javascript on line 46. File permissions were mentioned/questioned as a possible cause, but since file permissions being changed to read/write could not have cause a php file to go from not producing a header error to producing one, the ACTUAL problem is something else and needs to be found.

 

By finding the actual reason for the error, you would probably find what exactly the hacker changed.