PHP Session Remaining

Hi, all!

Have several PHP pages that are accessed via links in emails.  At the top of each page, I test for a specific session var being set.  If it's not, I know that the user came in via a link instead of logging in, and set the session vars I need later on.

 Problem is that the session still shows that variable even though they have not logged in, so the code is failing.  Here is the first part of the code:
session_start();

echo print_r($_SESSION, true);

if(!isset($_SESSION['sn_active'])) {
	echo 'new load<br>';
	$emaillink					= 'Y';
        $_SESSION['sn_active'] 		= 'Y';
	$_SESSION['sn_vialink'] 		= 'Y';
...

Open in new window


The echos were added for debugging.  The print_r shows the full set of session vars, including sn_active, which is my test variable.  I never see the "new load" text.

When a user exits the site (assuming they don't just close the browser window), the logout page supposedly destroys the session and the cookie.  Here's that code:
<?php
session_start();
if (isset($_SESSION['sn_via'])) $via = $_SESSION['sn_via'];
else $via = -1;
if ($_COOKIE[session_name()]) {
    setcookie(session_name(), '', time() - 42000, '/');
}
$_SESSION = array();
session_destroy();
?>

Open in new window


To further complicate, it works on one page, but not another, even though they use the same exact code at the beginning of the page.

Have confirmed that the cookie is being destroyed in both IE and Firefox.
Have tried removing the one call to a session var [sn_via] that is on the logout page.
Have tried adding a "random" parameter to the link to be sure it's not pulling from the cache.
Aside from the page name, the links are identical.

Why are the session values still there on this one page?

Thanks,
Bruce
springthorpeSoftwareAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

springthorpeSoftwareAuthor Commented:
Sorry, forgot the PHP version and server.  Running PHP 5.3.19 on Windows Server 2013.
Bruce
0
Julian HansenCommented:
"Problem is that the session still shows that variable even though they have not logged in"

I would start here - if the session has not been set and your code is behaving as if it has then you need to look at why.

Are you sure when testing you have done a complete clean out of your cache?

On FF right click page - view page info => Security => View Cookies => Remove all
0
Dave BaldwinFixer of ProblemsCommented:
I'm not sure what's going on but please see the example for session_destroy() on this page: http://php.net/manual/en/function.session-destroy.php
0
Acronis Data Cloud 7.8 Enhances Cyber Protection

A closer look at five essential enhancements that benefit end-users and help MSPs take their cloud data protection business further.

Ray PaseurCommented:
Agree with JulianH -- be sure that your browser tests are not caching anything at all.  I would recommend that you redesign the application so that it relies on long-term cookies instead of the PHP session.  The session might be set by a script on the server, but the client might not respond to the emails for a (relatively) long period of time.  So the session would time out sometimes and not time out other times.  Reliance on the session would seem to inject an unpredictable element into this design.

There are a lot of things you need to understand in order to design an application like this.  These articles cover the waterfront.  I'm sorry that there's not a magic bullet we can give you, but you will have much greater likelihood of success if you know what you're doing from end-to-end.

HTTP Client-Server.
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/A_11271-Understanding-Client-Server-Protocols-and-Web-Applications.html

An application that uses a "handshake" to confirm action via email:
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_3939-Registration-and-Email-Confirmation-in-PHP.html

The design of a login-logout script (includes a reliable way to ensure a "logout" happened):
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_2391-PHP-login-logout-and-easy-access-control.html

How PHP sessions work and don't work:
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_11909-PHP-Sessions-Simpler-Than-You-May-Think.html

These articles will be applicable to PHP 5.3+
0
springthorpeSoftwareAuthor Commented:
Thanks to all three of you for responding!
Julian: Verified no browser cookies present just before attempting.  They were not there.
Dave: Followed PHP.net's recommendations almost to the T.  Experimented with others found here on EE and other places.
Ray: Always a pleasure to hear from you!  Will look into your recommended reading, but it may be that I wasn't clear enough on work flow (or maybe I was and just don't understand your reply).  

The emails are sent to registered users that must perform a specific service within 2 days then post the results on our site.  They do not request the email, it is sent to them by their supervisor using our system.  The link in the email provides a coded uid and job number as parameters. It's intent is to make it easier to enter the info while they are in the field, saving them logging in, searching for the job, etc.

The theory is that they click the link in the email and we present them with a single page with the job info to update.  When entering the system in this manner, we restrict their navigation to any other page.  (Thus the test for the session.)  Don't see how long-term cookies on client machine could assist here, or how we could get them there.

The fundamental questions remain:
Why are the session variables there when they have not supposedly been loaded during the current visit, do not come from a cookie on the client, and were supposedly destroyed the last time that user accessed the system?  
Why do two different pages with the same exact code at the top of the page and accessed by the same user for the same job behave differently, one working fine and the other not? (I think this is the key to the solution but there are no differences in the pages down to the point of the session test.)

Thanks,
Bruce
0
Ray PaseurCommented:
How are you determining that these anomalous conditions occur?  For example, do you log each of the variables each time they are accessed?  Are there any other scripts that could access these variables without triggering logging?  How have you determined that session_write_close() is not needed?  

You cannot really "restrict their navigation" at all -- the internet does not work that way.  Anyone that wants to can simply type the URL of a web page at any time.   Application design must allow for this to happen without introducing side-effects.

Don't see how long-term cookies on client machine could assist here
The cookies would allow you to have a handshake between the point of origin of the email and the client who received the email.  This is an advanced topic in web development, and it's not completely intuitive, but it goes something like this.

"Supervisor" sends an email with a link containing a URL parameter.  Recipient clicks the link, causing a cookie to be set on the recipient browser.  This cookie has a long life, and uniquely associates the recipient with the action initiated by the supervisor's email.  Recipient does something - making HTTP requests - and each of these requests sends the cookie.  This cookie is a key to records in the data base, and thereby allows the server to identify the supervisor and the recipient and the action that has been requested of the recipient.  If any of the scripts in this chain of links is missing the cookie, you can discard the request because it is fraudulent.  If you discard a request, you would want to roll-back all of the database updates.  

If there is a PHP session involved, session cookies, expirations, garbage collection, and the like intervene in unproductive ways.  Timeouts can be short -- so short that lunch or coffee break can destroy the chain of evidence in the cookies and sessions.  If you control the authentication and handling of the cookies, these session-related variables are no longer in play and you can control the client-server flow of information.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
springthorpeSoftwareAuthor Commented:
Ray,
A great explanation! Should provide better authentication than I have now and I will implement it in the near future.  
Meanwhile, I found a way to avoid the immediate issue with the sessions.  I simply test for the presence of and value of one of the parameters passed in the link.  (It's unique to this particular functionality.)  If there and valid, I assign a new session_id that includes a random number, then start the session.  If not there, I just start the session as I would normally.
This method, while not the best approach, works on all pages involved and gets me over the hump until I can do better.
Thanks again for your time, effort and patience with me!
Bruce
0
Ray PaseurCommented:
Thanks for the points, and good luck with your project! ~Ray
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
PHP

From novice to tech pro — start learning today.