PDO error on function since a migration to PSO

[Paul-D]

Not sure if this is the right section as it is PDO. I used to use mySQL.

This website section has worked for nearly 10 years without fail. Early this year my website host upgraded the PHP server and as a result I had to move from mySQL queries to PDO queries. This web page refreshes every 2 minutes and after a while takes you back to log on again. After one of the refreshes’, I get an error shown in this image [BankSite-1.jpg]. I know where the error is: GetAllData(). This does not happen at every refresh

I have a separate secure functions file SecureFunctionsBankPDO.php. There are 2 SQLs in a function GetAllData() it depending on how I log in. It is the first SQL at line 62-65 that is causing the problem. It gets its only parameter $StartDate from the webpage which is being refreshed evert two minutes. It is set on line 29 of the webpage Statement.php and called on line 109. As this is worked each refresh, I can’t see how the variable is getting lost.

If I have missed a file then tell me. I think it is all you need. Thanks.

Topic should have said

PDO error on function since a migration to PDO My keyboards fault.

SecureFunctionsBankPDO.txt Statement.txt

Edited June 1 by Paul-D

[mac_gyver]

the most likely reason that GetAllData() returns a null is because $_SESSION['CounterValue'] isn't one of the expected values and none of the conditional code in the function is being executed. since there's no corresponding undefined index error massage, the session variable is set, but is probably an empty string.

what does using var_dump($_SESSION['CounterValue']); show?

note: session variables are inputs to the code for a page. you need to validate them before using them. if they are not valid, you either need to use a default value and continue or prevent running any code that's dependent on their value. if they are due to a user action, you need to setup and display a message for the user letting them know what to do to correct the problem. if they are set internally, you have a programming mistake somewhere that needs to be found and fixed.

edit: the global keyword only has meaning inside a function. the global $View; line in your main code does nothing and should be removed.

Edited June 1 by mac_gyver

[mac_gyver]

i have looked at your code further and it has a logic 'hole' that is probably related to the error and incorrect operation. in SecureFunctionsBankPDO, you have the following lines (these 'operational' lines of code should be in statement.php and be after the session_start() statement) -

$View = 'Show';
if (isset($_SESSION['CounterValue']))
    $View = $_SESSION['CounterValue'];

this is being included_once (you should use require for things your code must have) before the session_start() statement. therefore, that session variable cannot be set at that point and the conditional logic is always false. this leave $View set to 'Show'. however, $View is not directly used in the posted code. that session variable is being used. so, unless the Session_Init() function is setting that session variable, there's no code setting that session variable and the GetAllData() function cannot, well, function. if the Session_Init() function is responsible for setting that session variable, it is likely where the problem is at. you would need to post the code for Session_Init(). you could also have a problem with your code failing the session PK tests and redirecting to index.php, then perhaps redirecting back to the statement.php page?

i have a list of points for the posted code, many of which will simplify it -

1. the error related settings should be in the php.ini on your system, so that they can be set or changed at a single point. if you do put them into your code, put them in only once per page.
2. use require for things your code must have.
3. require/include/include_once are not functions. leave out the () around the path/filename.
4. don't copy variables to other variables for nothing. just use the original variable(s) that data is in.
5. the doctype is out of date.
6. you need to validate the resulting web pages at validator.w3.org
7. don't use a post method form for navigation.
8. if a query doesn't match any data, output a message stating so, instead of an empty section on the page.
9. functions should use call-time parameters for all input data, e.g. the $View input should be a call-time parameter to the GetAllData() function.
10. when you have a list of possible values, instead of writing out conditional logic to test for each value, put the values into an array and test using in_array().
11. you should use prepared queries, even in the case of using internally generated values with a query.
12. all the operational code should be in the main file, e.g. the code setting $View (which isn't actually used) from the session variable should be in the main file, not in the function definition file.
13. don't run queries inside of loops. e.g. the reason name. get this value in the main query by using a JOIN query, with the bank_reason table.
14. you should list out the columns you are SELECTing in a query. this is even more important when using JOIN queries.

 

[Paul-D]

Hi. I think this has been solved now. I have moved the 

if (!isset($_SESSION['Survalance']))
    $_SESSION['Survalance'] = '';

to Statment.php and I have modified the function GetAllData($StartDate, $View)

So now $View is passed so ther should be not problems. It seems to be wotking so I wiil test it.

As a question, does session_start() reset the timeout period for all sessions? Does updating a session variable also reset this?

Thanks for your help. This code was written nearly 10 years ago.

[mac_gyver]

14 minutes ago, Paul-D said:

$_SESSION['Survalance']

what does the session variable 'Survalance', have to do with this code? it's not present in any of the posted code.

i didn't specifically list it above, but 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

the initialization section should contain the session_start() statement, before any use of session variables, it should require the things that the page needs, such as the SecureFunctionsBankPDO.php file, and it should do things like get user data/permissions, perform whole-page access tests, ...

 

28 minutes ago, Paul-D said:

does session_start() reset the timeout period for all sessions? Does updating a session variable also reset this?

when php executes the shut-down code at the end of processing a request or you specifically call session_write_close(), it (should) write the session data to the file, which updates the modified time of the session data file.

if you are asking this because it seems like session data is being deleted now in cases where it previously wasn't (where you have a single user on a site), i seem to recall that it was stated in the documentation (currently nowhere to be found), and through observation of operation, that the session_start() that triggers garbage collection would not delete its own session data. i tested this not too long ago (within the past year), and the session data for the session_start() that triggers garbage collection is now being deleted. so, either i was mistaken about this operation, it has been changed (probably when the massive amount of register globals code was removed from the session handling), or the version i was using when i tested this wasn't updating the session data file if no changes were made to the session data.

[Paul-D]

As for $_SESSION['Survalance']. This was a typo. I copied it across. and changed the name of the session.

As for a session ending. If I set up a session at the start of the website log on. and do nothing for over 1/2 hour, the session naturaly expires on the server. I was thinking that every refresh would cause session_start() to refresh the session timeout on the server keeping the values and it could go for hours/days. That way I would not be worried about the session expiring. I am the only user of the website, but I would also assume on multi-user that each user would have their own session stored on the server. I was hoping that my sessions on the server would stay active.

It's a kind of catch all with the refresh. One of the variables has a date and time after which I would be redirected to the log on page regardless of the natural expiry of the session on the server.

Edited June 2 by Paul-D

[gizmola]

On 6/2/2024 at 4:25 AM, Paul-D said:

As for $_SESSION['Survalance']. This was a typo. I copied it across. and changed the name of the session.

As for a session ending. If I set up a session at the start of the website log on. and do nothing for over 1/2 hour, the session naturaly expires on the server. I was thinking that every refresh would cause session_start() to refresh the session timeout on the server keeping the values and it could go for hours/days. That way I would not be worried about the session expiring. I am the only user of the website, but I would also assume on multi-user that each user would have their own session stored on the server. I was hoping that my sessions on the server would stay active.

It's a kind of catch all with the refresh. One of the variables has a date and time after which I would be redirected to the log on page regardless of the natural expiry of the session on the server.

One thing of concern is that your site is leaking error information.  Unless you changed this just for the purposes of debugging, you should have display_errors = Off, and be logging the errors instead to a log file.

In terms of session timeout parameters, people are often given the impression that overriding the defaults with different runtime parameters is a solution, but the reality is, that the default handling will delete your session file, should garbage collection be run somewhere else on your site.  

The only way the timestamp on the session file will be updated, is if something in the session is updated.  This is partially based on the default session setting for session.lazy_write which defaults to true.  One way to handle this extension would be to update some session variable each time your refresh runs.

However, given that this is a personal system for you, the best solution in my opinion would be to implement a "remember me" feature, which is a fairly standard addition to many website systems.

The way you would handle remember me, is to add a security feature where your code (for you as the admin) sets a cookie in the future.

Practically speaking, this cookie can now only be set a year in advance, and for security reasons, these types of limits are subject to change depending on what the browser developers decide.  From what I've seen, Chrome for example, will only allow a cookie to set with an expiration a bit more than a year now.

But you would do something like this:

// Get these things from your user table:

//$userId
//$userName
//$userCreatedDate (user account was created)

// Generate the hash

$rememberMeHash = sha1(uniqid($userName, true) . $userCreatedDate . $userId);

// Now store this value (it's a 40 character hex string) in the row of your user table, for your personal/admin user.

setcookie(
  "someCookieName",
  $rememberMeHash,
  time() + (365 * 24 * 60 * 60)
);

 

After implementing this into your admin login, you then need to change your authentication to take this cookie into account.

• If authentication failed, check for your "remember me" cookie.
• If that value exists, see if there is a user who has that hash value in their user record.
• If found, handle this the same way you would if the user had authenticated with username/password and set the session up accordingly.

In essence this will keep your login available for a year at a time, just so long as this remember me cookie exists.