Session problem on Ubuntu only

[PHP5000]

Hi

In my php codes I start a session and set session variables for different things. They work perfectly well when I am viewing the page on a Windows computer.  However when I use ubuntu on the same computer to see the same page not only none of variables are set but also the session does not exist.  I noticed this by chance and it is quite puzzling because I always thought sessions ae set on the server.

Any idea what the problem is and how to fix it?

tx

[requinix]

PHP doesn't care what browser or operating system you're using to view pages. Your problem is going to be either (a) settings in the Ubuntu browser that prevents it from accepting the session cookie, or (b) a problem with the session cookie where the Windows browser is accepting it incorrectly but the Ubuntu browser is rejecting it correctly.
Actually there's a third possibility: a difference between how you're using the two browsers that is important but you don't know about and/or aren't mentioning. Such as a different hostname, source IP address that somehow matters, some sort of Windows authentication mechanism...

1. Check the network responses and confirm you're receiving a Set-Cookie on at least the first visit
2. Check that the cookie is being remembered by the browser/not being rejected for some error that should have been logged somewhere/isn't immediately expiring/something else
3. Check that the cookie is being sent in additional page requests

99% of the time the problem will show up in one of those three steps.

[PHP5000]

4 hours ago, requinix said:

1. Check the network responses and confirm you're receiving a Set-Cookie on at least the first visit
2. Check that the cookie is being remembered by the browser/not being rejected for some error that should have been logged somewhere/isn't immediately expiring/something else
3. Check that the cookie is being sent in additional page requests

Thanks for the quick response.  I have three questions now How x 3.

 

[requinix]

Use your browser's developer tools. If you're not sure how, spend some time getting familiar with them because they're invaluable for web development.

[PHP5000]

ok thanks

[PHP5000]

Anybody else has any suggestions or solutions? 

[requinix]

If you're asking, does that mean you tried what I said and couldn't find an answer and decided to not mention that? Or does it mean you saw my answer and decided you didn't like it and wanted something else instead?

[PHP5000]

Since you are asking let me explain.  The answer I got was like somebody explaining the problems with his car, and ask if anybody had a solution, and somebody else telling him to get a book on car mechanics. 

Although this was a valid suggestion, it is not a solution, which is what I was hoping for. None the less thanks for offering it.

I have been looking into the developer tools on the browsers (most online articles and videos are about Chrome for some reason.)  Meanwhile problem is still there. 

I did some tests and it turns out that Firefox has this problem no matter what operating system I use.  There are posts by other people on different forums and sites asking about it.  It is not a cookie setting or coding problem, because the exact same code sometimes work and sometimes does not work on the same browser on the same OS.  

I have devised a solution to get around this problem for the code I am working on, but I like to find out why this is happening on Firefox.

In case you are interested to know what I am trying to do:  In a website there is an admin section and a person get access after logging in.  This is supposed to set a session variable and a code on top of every page will check if this variable is set or not.  If not access is denied.  Without ability to set session variables the admin logging I am making is screwed.

 

Edited November 10 by PHP5000

[requinix]

That was a great, detailed answer that gave me a lot more information to work with than what you first posted.
Knowing what you're doing with the session, more than just "start a session and set session variables for different things", tells me about the sorts of practices you might be following, how they might work and might not work, and gives me a good foundation I can use to ask you questions that will make more sense.
Knowing that you're trying to understand the developer tools but still aren't quite able to work with them, more than just "How x 3", means I feel more invested in helping you to learn. Like I said before, those tools are invaluable when it comes to a lot of web development work, and there's a high likelihood that those tools will be able to explain what's going wrong.

But knowing that you've tried this with Firefox and that it doesn't work no matter what is the best part. Web browsers don't just randomly decide how they will work. If Firefox doesn't work but Chrome might, that strongly suggests something is wrong with what you're doing - and I mean that in a very general sense of "you are doing a thing and there's a problem with it", as opposed to "you are doing a thing and Chrome isn't working correctly".

1. If you haven't done it yet, the first thing to check is the console in the developer tools. I believe F12 on any browser will pull them up. It should give you some sort of collection of tools or tabs, and one them should be clearly marked as Console. Have the tools open as you log into the admin (like in Firefox). Do you see any errors or warnings?
2. There's also a Network tab. If there's no messages then (that's surprising, but) you'll have to look a little closer at what's happening. Provided the tools were open when you logged in, the tab should show a request to your login page or AJAX endpoint or whatever. That's where cookies may have changed. Open up the information for the request and check the Response headers. What does it say for a Set-Cookie?
3. It might not have anything. That's fine. Now check the Storage tab and look for your site's cookies. One of them will be the session cookie, probably named like PHPSESSID. What are the settings for it? (Specifically, the path.) Also, what are the URLs for your login and admin pages? (Specifically, the path portion.)

[jodunno]

On 11/8/2024 at 8:45 PM, requinix said:

Use your browser's developer tools. If you're not sure how, spend some time getting familiar with them because they're invaluable for web development.

 

On 11/11/2024 at 12:00 AM, PHP5000 said:

Since you are asking let me explain.  The answer I got was like somebody explaining the problems with his car, and ask if anybody had a solution, and somebody else telling him to get a book on car mechanics.

I do not see a reference to a book. I find the answer to be sufficient for trouble shooting. And i will add to this:

https://firefox-source-docs.mozilla.org/devtools-user/
https://developer.chrome.com/docs/devtools
https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/landing/
https://developer.apple.com/library/archive/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/Introduction/Introduction.html

https://www.php.net/manual/en/book.session.php

browser issues: disabling all cookies will include session cookies in certain browsers.
clear your cache before testing.

check php session file permissions, typical path is /var/lib/php/sessions
check php.ini for PHP session path location: /etc/php.ini
search for session.save_path in php.ini

check PHP error logs: query a search engine for error log locations of your preferred web server.
 

I also wonder what you mean by "Ubuntu only". So this problem doesn't happen in OpenSUSE or Linux Mint? or you mean that the problem is not with a Microsoft Windows system, rather a Linux based system like Ubuntu?

 

 

[PHP5000]

Thank you for your replies.  Let me give you an update:

1. I have been using the same techniques and similar codes for the past few years and this is the first time I am experiencing these problems with sessions.  The major difference is that the laptop I am working on has dual boots (Win11 and Ubuntu).  I am sure of the code.  Something else must be the problem.  There are known problems with dual boot computers (for example Win11 clock is always wrong)

2. I have done extensive (over 100) tests under different conditions.  The problem is not limited to Firefox.  When I use Librewolf (which is in the same family of firefox I must admit) the same problem happens too, under windows and Ubuntu both.

3.  The reason I say it can't be the code is that sometimes the system works perfectly, then for no reason at all it does not.  I am logged in as admin and can view different pages then suddenly I click on another page in admin menu and I get access denied which is an indication of session having been terminated.  (Not the same page all the time.  In fact the same page that I could see before now does not give access).  To test I open another browser and log in and go to the same page (without touching the code) and everything works.  This is driving me batty.  I find no logic to it.

Since requinix asked for it I will include the code maybe you guys can see something I am missing:

I set the session variables in logging in page with:

$_SESSION["AdmKeyy"] = "T54";                                
$_SESSION["AdmUserr"] = $Usrc;  << username that just logged in.
$_SESSION["Admlevell"] = B;             << determines the level of access

 

Then to check (on top of every protected page:)

if ($_SESSION["AdmKeyy"] != "T54")
    {
    print "<font color=red><b>You are not authorized to view this section." ;
    exit();
    }

 

There is a log out page with the following code:

session_unset();
session_destroy();

 

I am certain at some point session gets terminated (there are other session-dependent functions which stop working as well).  I have checked my pages one by one to see what could cause it.  (for example starting another session by mistake) There is none.

I thank you in advance for taking the time to look into this. If you figure it out, and pass by Canada at some point, beer is on me.

 

Edited November 12 by PHP5000

[jodunno]

19 minutes ago, PHP5000 said:

Then to check (on top of every protected page:)

if ($_SESSION["AdmKeyy"] != "T54")
    {
    print "<font color=red><b>You are not authorized to view this section." ;
    exit();
    }

and hopefully you also have session_start(); before that line of code on every individual page that needs to continue the previously started session. we cannot see your code, so we are feeling around in the dark for a flashlight...

[PHP5000]

Yes of course without it security would not work on any page.

[jodunno]

1 hour ago, PHP5000 said:

Then to check (on top of every protected page:)

if ($_SESSION["AdmKeyy"] != "T54")
    {
    print "<font color=red><b>You are not authorized to view this section." ;
    exit();
    }

okay but now you need to take a closer look at your code. Specifically, not equal to.

if ($_SESSION["AdmKeyy"] !== "T54") { }

it seems as though your sessions may not be coded properly. Requinix is a pro and will easily be able to spot any problems. Perhaps you could post a full example of your session code.

[dodgeitorelse3]

doesn't the value B need to be in quotes?

$_SESSION["Admlevell"] = B;             << determines the level of access

 

[PHP5000]

Yes it does.  My mistake when typing here. In the actual code it is correct.

Here is example of two pages on my site which should work and doesn't.  It requires session variable to work.

I do not have access to a second hosting so I appreciate if somebody actually try and see if this works on their server or not.  I am beginning to think we have server problems with my current host company (WHC.ca - avoid them at all cost).

 

Theses are two pages.  The first has a simple form that sends the value selected to the second page (Cart1.php) .

The second page receives the value and generate a session variable with it.  Then redirect back to the first page.  We should see this session variable now but we don't.

 

//  ---- first page called form.php sends the variable to page called Cart1.php ----

<?

session_start();

print "<html><body>

<form method=POST action=Cart1.php>
<select name=PQty1>
<option value=->Please select quantity</option>";

for ($i=1;$i<=20;$i++)
    {
    print "<option value=$i>$i</option>";
    }

print "</select><input type=submit value=Add></form><br><br>";

print $_SESSION["PQty1"];

print "<br><br></body></html>";

?>

//  ---- second page called Cart1.php registers the session variables and redirect back to form.php ----

<?php
session_start();
print "<html><body>";
$PQty1 = $_POST["PQty1"];
$_SESSION["PQty1"] = $PQty1;
print "</body></html>";
header("Location: form.php");  // complete the link to loction of page form.php
or die();
exit();
?>

 

Do you see any errors?

 

 

 

Edited November 13 by PHP5000

[jodunno]

3 hours ago, PHP5000 said:

Do you see any errors?

form.php start tag should be <?php

you are assigning user input directly to a session variable without validating the input. I recommend casting to an integer intval() and using is_int to verify a number.

or die(); will cause an error. simply exit after a header redirection: header("Location: form.php"); exit;

if session cookies are not being set in the browser, then you will have empty session files (the browser will continue starting a new session). Which brings you back to the suggestions posted by requinix.

 

[PHP5000]

form.php does start with <?  Just above the session_start();

The only person who has access to this test page is me so the input will be correct  This is made only to test.

Which suggestion are you talking about?

I think I have found the root of my problems.  Every time a redirect is done the session goes off.  I have no idea why or how, but this statement is based on many many tests.  Maybe this point to something?! 

 

 

[jodunno]

well i have changed a few things in your script which irritate me but the majority of the code is unchanged. I tested your code in xampp and i do not have any issues with the session. I have to enable cookies in Firefox or the session will not function but everything is working as expected after i enable cookies.

<?php
session_start();

print "<html><body>

<form method=POST action=Cart1.php>
<select name=PQty1>
<option value=>Please select quantity</option>";

for ($i=1;$i<=20;$i++) {
  print "<option value=$i>$i</option>";
}

print "</select><input type=submit value=Add></form>";

if (!empty($_SESSION["PQty1"])) { print "<p>".$_SESSION["PQty1"]."</p>"; }

print "</body></html>";

?>

<?php
session_start();
if (is_int(intval($_POST["PQty1"]))) { $_SESSION["PQty1"] = $_POST["PQty1"]; }
header("Location: /p5k/form.php"); exit;
?>

you have to check the local storage to see if your session cookie matches that which is sent by the server.

[PHP5000]

10000 Dank, lieber Freund. Ihre Hilfe ist von unschätzbarem Wert. Ich habe ein paar Probleme gelöst, nachdem ich Ihren Code gesehen hatte. Außerdem wird die Sitzung anscheinend beendet, wenn auf eine URL umgeleitet wird, die mit http:// beginnt. Nochmals vielen Dank.

Quote

10000 Thanks, dear friend. Your help is invaluable. I solved a few problems after seeing your code. Additionally, redirecting to a URL that begins with http:// appears to terminate the session. Thanks again.

 

[jodunno]

Danke schön. Sehr nett, aber:

a full uri should not be a problem.

<?php
session_start();
if (is_int(intval($_POST["PQty1"]))) { $_SESSION["PQty1"] = $_POST["PQty1"]; }
header("Location: http://localhost/p5k/form.php"); exit;
?>

you could also submit to the same page:

<?php

session_start();
print '<html><body>

<form method="POST">
<select name="PQty1">
<option value="">Please select quantity</option>';

for ($i=1;$i<=20;$i++) {
  print '<option value="'.$i.'">'.$i.'</option>';
}

print '</select><input type="submit" value="Add"></form>';

switch ($_SERVER['REQUEST_METHOD']) {
  case 'POST':
    if (is_int(intval($_POST["PQty1"]))) { $_SESSION["PQty1"] = $_POST["PQty1"]; }
    if (!empty($_SESSION["PQty1"])) { print '<p>'.$_SESSION["PQty1"].'</p>'; }
  break;
}

print '</body></html>';

?>

still, the general rule for redirection is to follow the redirection with exit. Otherwise, the script will continue executing to the end of the script. Not good if you have data after the redirection, which should not be processed.

If you are happy and the script is working, then i am happy for you. 

 

I hope that you have a pleasant day,

John

[jodunno]

On 11/13/2024 at 2:13 AM, PHP5000 said:

<?php
session_start();
print "<html><body>";
$PQty1 = $_POST["PQty1"];
$_SESSION["PQty1"] = $PQty1;
print "</body></html>";
header("Location: form.php");  // complete the link to loction of page form.php
or die();
exit();
?>

well it bothers me that you think that a full uri is a problem, so i revisit your code and voila! you have output before the header, which is an error. You must use header before any output is sent. I apologize for not noticing this error beforehand. I overlooked it yesterday. So perhaps that was your problem all along. Meantime, i have to work on reading and comprehension skills. I missed that yesterday. yikes!

[PHP5000]

jodunno thanks for your reply and being persistent in solving the problem.

I corrected the redirect problem by removing all outputs and spaces.  That solved one problem very well. 

The problem of sessions getting terminated by themselves still exist.  (So redirect was not the cause of it.)  I tested my pages at 9:15 this morning and everything was ok.  At 9:20 I repeated the exact same tests with the same data and session does not work. In all years of my programming I have never seen such a thing. I am stating to think some crazy person in the hosting company is screwing with my code.  I did not change anything from 9:15 to 9:20 so why is it not working now!  Could disconnection from internet kill the sessions?  A momentary disconnection is the only thing I can think of, although technically it shouldn't.  Not only the session in progress is no longer working, I can not even create a new one while I can see Internet connection is working.

So to summarize: what could prevent setting a new session if nothing is changed in code, browser, OS, username and password or anything else?

Edited Saturday at 03:21 PM by PHP5000

[mac_gyver]

do you have php's error_reporting and display_errors set so that php will help you by reporting and displaying all the errors it detects? error_reporting should always be set to E_ALL. on a live server, you can temporarily set display_errors to ON to get immediate feedback as to any problems. these settings should be in the php.ini on your system, but can temporarily be put in your php code, right after the first opening <?php tag.

if php's output_buffering setting is on (another bad decision by php), you can have output before a header() statement and the header() will work. you should check using a phpinfo() statement to see what this setting is, as it also hides non-fatal php errors and any debugging output from your code.

a full URL is not a problem. however, if the protocol changed, e.g. from https to http, the session won't match, because session cookies are kept per protocol.

you are doing this on live web hosting? have you set your session_save_path to be to a location within your hosting directory tree, outside of/below the htdocs folder, so that all the session garbage collection by all the other hosting accounts isn't deleting your session data files? if your session data files are in the default tmp folder with all the other accounts, the shortest session.gc_maxlifetime of all those accounts is what will affect your session data files.

 

On 11/12/2024 at 10:42 AM, PHP5000 said:

I set the session variables in logging in page with:

$_SESSION["AdmKeyy"] = "T54";                                
$_SESSION["AdmUserr"] = $Usrc;  << username that just logged in.
$_SESSION["Admlevell"] = B;             << determines the level of access

the only user data you should store in a session variable upon login is the user id (autoincrement primary index.) you should query on each page request to get any other user data, such as a username, permissions, ... this is so that any changes made to this other user data will take effect on the very next page request after they have been changed. do you really want a situation where you have demoted or banned a user and they can continue to visit your web site because their session data says they can?

 

On 11/12/2024 at 10:42 AM, PHP5000 said:

There is a log out page with the following code:

session_unset();
session_destroy();

and is this inside of code testing if a post method form has requested the page, so that it won't get executed just because a browser/client has made a get request to the page? browser's are now doing things like pre-requesting pages that are in your browser's search history when you start typing things in the address bar. also, a session can hold data other then who the logged in user is. you should only unset those session variable(s) that are specific to the logged in user.

the code you have shown has the form processing code and the form on separate pages, with a bunch of extra redirects. this results in nearly 2x the amount of code, provides a bad User eXperience (UX), and depending on how you are getting data/messages back to the form, is open to phishing attacks and cross site scripting. the only redirects you should have in your application code are upon successful completion of post method form process and they should be to the exact same URL of the current page to cause a get request for that page. this will prevent the browser from trying to resubmit the form data should that page get browsed back to or reloaded, where someone can use the browser's developer tools to see what the form data, such as the password, is.  the code for any form and related form processing should be on the same page. the code for any page should be laid out in this general order -

1. initialization
2. post method form processing
3. get method business logic - get/produce data needed to display the page
4. html document

[gizmola]

I am getting to this question late, and I see that people have been diligently working on it, but I do want to interject that the environment is very important here.

Are you testing something locally, or even running a local app?

Hopefully you are aware that the default behavior for php sessions is to set a cookie.

Hopefully you are also aware that cookies are the responsibility of the client/browser to accept and once accepted, to return to the server in the HTTP header of every subsequent HTTP request.

However, cookies also are relevant to a domain (and in some cases) to a subdomain.  

For security reasons, domains must have at least one dot in them, or browsers should not set the cookie.  

Because there is so much confusion regarding the use of localhost as an alias, and how it may or may not work as a domain, I never utilize it in development.  

I will use the .test TLD as it (along with a few others) has been designated as a TLD that will never be allowed.  You are then free to odd domains and subdomains as you like, which you can put into your /etc/hosts file.  

I tend to use a project name, so I might set something like this up for project foo:

// /etc/hosts file
127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost
127.0.0.1	foo.test www.foo.test

You can of course have as many of these aliases as you want added to each line.

There are also tools people commonly use like dnsmasq to manage a home DNS setup and can even be used on your workstation, but that's far more complication than I want to bring up.

 

In summary, again without full context here, this could be environmental, depending on where the server is running (and if this is a local/intranet server) .