Jump to content

Session_Id() Regenerates After Refresh


Recommended Posts

Posted

session_id() is very important to me. It is supposed to be constant (I think) until browser is reopened. But here when I run this php script I always get new id:

 

session_start();

echo session_id();

 

As I'm reading http://stackoverflow.com/questions/15911817/session-start-creates-new-session-every-refresh some say that this could be due to:

1) the session_save_path is not writable

 

I run this:

 

if ( !is_writable(session_save_path()) ) {
echo 'Session save path "'.session_save_path().'" is not writable!';
}

And it says: "Session save path "" is not writable!"

 

Harris says: "If that is the case, you will need to have the server admins give what ever user your webserver runs as permission to write to the /tmp directory." Can I have this?

 

 

 

2) session.cookie_secure is On

 

I do not know what this means but I will research it in the meantime.

 

3) You do not use https

 

And this is true.. My .heliohost.org website is http, not https. If that's the case, will you ever upgrade to https?

 

So because it's 2 out 3 I'm writing it here, I'm assuming it's your fault. But in case it isn't or in case you can't answer this quickly I'm looking this topic: http://stackoverflow.com/questions/8028957/how-to-fix-headers-already-sent-error-in-php even though I didn't get this error but I have many programming mistakes listed there so I will try to see what I can do myself.

Posted

I'm not sure if there's a problem or not. Krydos is the one who would be able to check. Applications that use session IDs seem to work fine for me and everyone else here though, and I can see that my session IDs in the system I run don't change unless I do something where it should do so (such as logging out). I'd imagine there'd be a lot more complaints if this were broken.

 

/tmp is writable on Tommy (script showing an is_writable("/tmp")...http://rax2.heliohost.org/temp/tmp.php). It's worth noting that on our servers, Apache runs as nobody, but PHP scripts run as the user who owns the script.

 

And this is true.. My .heliohost.org website is http, not https. If that's the case, will you ever upgrade to https?

 

 

We already support it, but you need to acquire and install a certificate for your domains. There's a guide on the wiki for using Let's Encrypt/ZeroSSL for a free one, but you need to get a new one every 90 days. You can get a paid certificate from a CA if you want one that lasts longer. We don't sell certificates.

 

SSL can be set up from https://tommy.heliohost.org:2083/frontend/paper_lantern/ssl/index.html

Posted

I made a php script with your code and it gives me the same session ID on Tommy over and over even without https:

 

<?php
 
session_start();
echo session_id();

http://krydos.heliohost.org/session/

 

Perhaps something is going on with your browser? Incognito mode? What happens when you try a different browser?

Posted

<!DOCTYPE html>
<?php      
if ( !is_writable(session_save_path()) ) {
   	echo 'Session save path "'.session_save_path().'" is not writable!';
}    
session_start();    
echo "Session id: ".session_id();
?>

http://hypo.heliohost.org/

Try it out. I detected it in Chrome's Incognito mode, idk if that was the cause. I tried in Normal modes of Chrome, Firefox and Internet Explorer, it regenerates in all of them too. For me, in your link it doesn't change too.

 

Appearently there is no session_save_path... and it makes sense, if there is nowhere to save, it is not being saved and thereby regenerated every time. Or not, because empty string means it would save in the directory the .php is running from?

 

Update: Ok empty string from session_save_path() means temporary directory. When I run sys_get_temp_dir()

function, it returns: /tmp but idk if that's totally good, shouldn't it return hypo/home/tmp?

Posted

Your code is broken. It will never work because the headers were already sent. You cannot have ANY html, blank lines (outside of Php block) or other output before session_start(). Once something sends output to the browser, it won't work.

 

In your case, you need to delete the doctype line or move it so its sent by an echo statement after the session_start call. The headers are sent when that line is processed, then php tries a head cookie for the session and fails. You just aren't seeing the "headers already sent by" error because we have error_reporting turned off.

Posted

You just aren't seeing the "headers already sent by" error because we have error_reporting turned off.

@Krydos, why do we have error_reporting turned off?

Posted

 

You just aren't seeing the "headers already sent by" error because we have error_reporting turned off.

 

@Krydos, why do we have error_reporting turned off?
I've always wondered the same thing. The errors do log in the error_log, but don't show up on screen by default (and if they're fatal, you get a 500 error, which is useless). I've seen others asking about this too...only for the response to be "what's in the error_log?"

 

Our old servers used to show the errors (E_WARNING and higher) on the screen by default and log them to the error_log, unless you specifically turned off showing them with an error_reporting(0); in which case they went in the log only.

 

Can we get the old behavior back? It's much less confusing than the current settings.

Posted

Can't you just change the error reporting level in the script if you need it? I've always just looked in the error_log file myself. The settings that we have now are just the default settings that cPanel installs PHP with.

Posted

Yeah, thanks people. There were invisible charachters in the beginning of the file. In hex editor they look like this: EF BB BF.

Krydos how did you remove them? To which enconding did you change it?

Posted

Can't you just change the error reporting level in the script if you need it?

The reason I disagree with errors being off is that its a lot more confusing this way, especially for new users. Every other host I've used has errors on by default, whereas we produce a meaningless 500 error, and most won't know to look in the log/turn on the errors.

 

Also, Stevie and old Johnny were both set to show errors by default. I didn't even realize they were off until I spent 45 minutes figuring out a 500 error...and discovered a missing semicolon caused it. I had expected the error to show up since I never disable them in my scripts.

Posted

display_errors = On
for all versions of php on Tommy now. Here is an example file where the line is missing a semicolon http://krydos.heliohost.org/error.php How does that look?

 

Krydos how did you remove them? To which enconding did you change it?

I opened the file with vim, and it says the encoding type along the bottom of the screen. It caught my eye because when a file has standard linux encoding it doesn't show anything there. This is actually a really common reason for cgi executables to cause 500 errors, but it rarely makes a difference with php scripts. As you could see the php still executed, but threw header already sent errors. To fix the encoding I just copied the code from the broken file, deleted the broken file, created a new file with the same name in vim and pasted the code back in.

 

I think your real question isn't how did I do it, but rather how can you do it though so it doesn't happen again in the future right? I would recommend creating the file through cpanel file manager and then copy/pasting the code in if you think you might be having encoding issues.

 

root@tommy [/home/hypo/public_html]# file -i *
cgi-bin:            inode/directory; charset=binary
count:              application/octet-stream
css:                inode/directory; charset=binary
cus.txt:            text/plain; charset=us-ascii
error_log:          text/plain; charset=us-ascii
images:             inode/directory; charset=binary
indexgood.php:      text/x-php; charset=us-ascii
index.php:          text/x-php; charset=us-ascii
js:                 inode/directory; charset=binary
listenerold.php:    text/x-php; charset=us-ascii
listener.php:       text/x-php; charset=us-ascii
paypal_success.php: text/html; charset=us-ascii
resp.txt:           text/plain; charset=us-ascii
I'm not sure because I already deleted the broken file, but I believe it was octet-stream just like your count file.
  • Like 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...