Knowledge Is Power Testing Results

[hacker]

After creating a successful PayPal Sandbox transaction and returning to thanks.php I'm greeted with the following message echoed to the viewport:

 

"Thank you for your payment! You may now access all of the site's content for the next year! Note: Your access to the site will automatically be renewed via PayPal each year. To disable this feature, or to cancel your account, see the "My preapproved purchases" section of your PayPal Profile page."

 

However, when I try to view the subscription material without first logging out and then logging back in again, I receive the message:

 

"
Thank you for your interest in this content. Unfortunately your account has expired. Please renew your account in order to view any of the PDFs listed below."

 

Since the buyer is logged in (just after registering) and has just paid, they should be able to immediately view the subscription material without logging out and in again, shouldn't they?

 

Thank you,

Hacker

[Larry]

Well, yes, but...

 

The issue is that a session var reflects the user's expiration. Until the user pays, the expiration is in the past. Once the user pays, the expiration gets updated to the future. The problem is that the official notice of the account being activated is through the IPN script, not thanks.php. The IPN script cannot change the user's session value because the user isn't accessing the IPN script. You could have thanks.php change the session value, but that could make the site vulnerable for fraud as it will assume that the user paid. You could have thanks.php re-select the expiration from the database and update the session value, but that will only be meaningful it it's done AFTER the IPN script runs, and there's no guarantee which will happen first.

 

You could try re-checking expired dates when the user goes to view content, in the hope that by then the IPN script will have done its thing.

 

Basically, this is one of those situations where there are a couple of options, each with its plusses and minuses, and you just need to decide for yourself what you're most comfortable with.

[hacker]

Well, yes, but...

 

The issue is that a session var reflects the user's expiration. Until the user pays, the expiration is in the past. Once the user pays, the expiration gets updated to the future. The problem is that the official notice of the account being activated is through the IPN script, not thanks.php. The IPN script cannot change the user's session value because the user isn't accessing the IPN script.

 

What are the ramifications to inserting the following line of code after the update query to the users table in ipn.php?

 

$_SESSION['user_not_expired'] = true;

 

In other words, incorporate $_SESSION['user_not_expired'] = true; as the else condition to:

 

if (mysqli_affected_rows($dbc) != 1) {

trigger_error('The user\'s expiration date could not be updated!');

}

 

You could have thanks.php change the session value, but that could make the site vulnerable for fraud as it will assume that the user paid. You could have thanks.php re-select the expiration from the database and update the session value, but that will only be meaningful it it's done AFTER the IPN script runs, and there's no guarantee which will happen first.

 

You could try re-checking expired dates when the user goes to view content, in the hope that by then the IPN script will have done its thing.

 

Basically, this is one of those situations where there are a couple of options, each with its plusses and minuses, and you just need to decide for yourself what you're most comfortable with.

 

Thank you for the reply Larry...

Hacker

[Larry]

The ramifications are that adding that line will cause an error. As I say in the part you quoted just before that, the user isn't accessing ipn.php; a PayPal process is. So there is no session established in the ipn.php script, let alone a session for any particular user. Put another way, although it's the user going through PayPal that causes the ipn.php script to be accessed to update that user's account, the actual request of the ipn.php script is an entirely separate process from what the user is doing.

[hacker]

The ramifications are that adding that line will cause an error. As I say in the part you quoted just before that, the user isn't accessing ipn.php; a PayPal process is. So there is no session established in the ipn.php script...

 

That's what I was afraid you were going to say. Why then was the following included in ipn.php and ipn_log.php?

 

// Require the configuration before any PHP code as the configuration controls error reporting:

require ('./includes/config.inc.php');

// The config file also starts the session.

 

I'm not trying to be annoying, I'm just trying to learn this stuff with a lot of other stuff going on around me.

 

...let alone a session for any particular user. Put another way, although it's the user going through PayPal that causes the ipn.php script to be accessed to update that user's account, the actual request of the ipn.php script is an entirely separate process from what the user is doing.

 

I'll try to reconcile all that.

 

Thank you Larry,

Hacker

[Larry]

The reason that the ipn.php script includes the configuration file isn't because of sessions. That's irrelevant to the ipn.php script. What is critical is that the configuration file defines all the key constants and functions that the site needs to run. For example, the ipn.php script wouldn't know where to include the database connection script from or how to handle errors without including the configuration file first.

[hacker]

...For example, the ipn.php script wouldn't know where to include the database connection script from or how to handle errors without including the configuration file first.

 

Ah ha... thank you Larry.

 

I'm going to print this thread now.

 

Hacker