PHP problem, seemingly caused by session expiration

In my application, all URLs are a PHP scriptlet that looks like this:

<?php echo Constants::URL_LOGIN ?>

Open in new window


I left my browser on a page in my application for days, and when I tried to click a link, the URL on the browser looked like: /public/<?php echo Constants::URL_LOGIN?>. Needless to day, that won't work and caused an ugly and ungraceful error message on the page (something like Access Forbidden, which is insignificant because I know the URL is messed up).

First of all, I'm puzzled because the value in that scriptlet is not in the Session. So even if the session had expired, why would that be affected?

Secondly, this type of outcome is not acceptable in my application. If the session expires, I would want it to go to my login.php page.

Can someone please explain to me this seemingly anomalous behavior, and please provide me a way to get around this gracefully so that I can cleanly bring my application to my login.php without displaying the browser's ugly nasty error message?

Thanks.
elepilAsked:
Who is Participating?
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.

Ray PaseurCommented:
Well, I can't explain anomalous behavior because I didn't observe it (there are too many configuration and environmental variables to make guessing worthwhile) but I can explain how PHP sessions work and how PHP client authentication works.

PHP sessions:
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_11909-PHP-Sessions-Simpler-Than-You-May-Think.html

PHP client authentication (uses sessions):
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/A_2391-PHP-login-logout-and-easy-access-control.html

This statement may be a bit off base:
If the session expires, I would want it to go to my login.php page.
Because HTTP is a stateless client/server protocol, there is no "it" to go anywhere.  There are only requests and responses.  The server cannot initiate any action.
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/A_11271-Understanding-Client-Server-Protocols-and-Web-Applications.html
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
elepilAuthor Commented:
Ray,

While I appreciate your response, but you have inundated me with links that do not address my issue at all.

Let me repeat my problem succinctly this time.

I had a browser that has been sitting on a page of my application for days. I tried to click a link that should've navigated it elsewhere in the application but got an error message instead. The cause was because my application tried to redirect to a URL that included PHP script. The browser's URL field showed : http://localhost/public/<?php echo Constants::URL_LOGIN ?>. instead of http://localhost/public/login.php. It is evident that the problem is that PHP did not interpret the scriptlet.

I brought in the subject of the "session" for the lack of a better explanation why this would happen. I am trying to get an explanation why something like this would happen, and a way to prevent it.
0
Dave BaldwinFixer of ProblemsCommented:
It is evident that the problem is that PHP did not interpret the scriptlet.
That is in fact the source of your problem.  It has nothing to do with sessions.  Was the link originally on an HTML and not a PHP page?  For whatever reason, PHP did not run on the page and replace <?php echo Constants::URL_LOGIN ?> with a value.
0
Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

Dave BaldwinFixer of ProblemsCommented:
Is <?php echo Constants::URL_LOGIN?> inside an 'echo' statement where it would not be interpreted?  Like this?
echo "/public/<?php echo Constants::URL_LOGIN?>";

Open in new window

0
elepilAuthor Commented:
To Dave Baldwin. Thanks for responding.

Everything is on a PHP page, and the scriptlet is exactly as I described. This happened on a browser that's been sitting on a page in my application for days. Somehow, something caused the PHP interpreter to no longer function, and I can't figure it out. This is not the first time this has happened, too.

By the way, I actually had several browsers up for days. I had an instance of Opera, Safari, and Firefox up. All three got the same error, so it's not the browser. So it's either PHP or Apache that caused this. When I made this post, I was hoping someone has had this problem before.
0
Dave BaldwinFixer of ProblemsCommented:
No, it didn't happen that way.  If that page has been sitting in your browser(s), then the PHP Never ran or that part is formatted so it doesn't get processed.  And it has nothing to do with Apache either.

PHP runs only when you make a page request.  It processes the code, sends the data to the browser and it is done.  Completely done until the next request.
0
elepilAuthor Commented:
Dave,

On that day I left those browsers at the pages they were in, had I clicked any link, everything would've been fine. From my experience, even after a day later, this problem would not have occurred.

To me, this problem has something to do with the extended inactivity of these browsers (which is about 3 days or more). Here's how the actual link looks like:

<input id="btnDashboard" type="button" value="Back To Dashboard" onclick="location.href = '<?php echo Constants::URL_DASHBOARD ?>';" tabindex="17" />

Open in new window


That's actually one of the links that failed. It's in a file called editmyinfo.php. So your initial suspicion that it might not be in a PHP page is simply not the case.

Is there any kind of 'timeout' in PHP or Apache configuration that might cause the server not to run my page through the PHP interpreter?
0
Dave BaldwinFixer of ProblemsCommented:
No, you're trying to think of it backwards still.  When you make the original request, PHP processes the code and sends to the browser.  It is Done at that point.  It does not run again and make any changes in your page that is sitting in your browser.  That page can sit there in your browser until the end of time and nothing more will change.  PHP will Not run until another page request is made.  Any errors that are in the page were made during the original request.

If this line below is inside an 'echo' statement, the <?php will not be processed because it is simply part of a string at that point.
<input id="btnDashboard" type="button" value="Back To Dashboard" onclick="location.href = '<?php echo Constants::URL_DASHBOARD ?>';" tabindex="17" />

Open in new window

0
Ray PaseurCommented:
Sounds like a server configuration variable got changed.  If the server used to parse PHP and now it no longer parses PHP, something happened in the days since the last PHP page worked correctly.  Who knows what could have happened?

You may think the links I posted are irrelevant, but in fact they are not.  If you understand the stateless nature of client/server protocol you also understand that a browser is never "sitting on a page."  It doesn't work that way, full stop.

A browser that is sitting inactive for days is really an extreme edge case, so I'll sign off on this question.  If you want to learn how the protocols really work, the articles can show you.  Best of luck with it, ~Ray
0
elepilAuthor Commented:
Dave, you said:

Any errors that are in the page were made during the original request.

Well, what I didn't do at the time the error occurred was to do a View Source prior. I imagine it should've look like:

<input id="btnDashboard" type="button" value="Back To Dashboard" onclick="location.href = '/public/dashboard.php';" tabindex="17" />

Open in new window


I expect PHP to have substituted my scriptlet with the actual URL before it returned the page. I cannot conceive how the interpreted page, i.e., the page PHP sent back, could possibly still contain a scriptlet. It's not like my code has never worked. It works 100% of the time with the PHP scriptlet in there being interpreted correctly by PHP during my development.

I now have to wait 3 or more days when the error is expected to occur again. Prior to clicking any links, I will first do a View Source to check how the link looks like. If it's a PHP scriptlet as you're saying, I would be shocked. So I'll get back on this then to disclose the results.
0
elepilAuthor Commented:
Ray, you said:

If you understand the stateless nature of client/server protocol you also understand that a browser is never "sitting on a page."

You lost me on that one. If you're saying the page currently being displayed will somehow change on its own (unless it's being refreshed by some timer) is something I've never encountered.
0
Ray PaseurCommented:
You can see what the code does on my server here.  Just use "view source."
http://iconoun.com/demo/temp_elepil.php
0
elepilAuthor Commented:
Ray, I got a blank page because it bombed out due to Constants.php not being there.

View source shows:

<input id="btnDashboard" type="button" value="Back To Dashboard" onclick="location.href = '<br />
<b>Fatal error</b>:  Class 'Constants' not found in <b>/home/iconoun/public_html/demo/temp_elepil.php</b> on line <b>1</b><br />

Open in new window


I'm not sure what your point is.
0
Ray PaseurCommented:
Actually it did not really bomb out at all -- it did more or less what it was expected to do.  It is an HTML document that consists of a single input control tag.  The control has an onClick handler.  The onClick location.href is populated by an embedded PHP script (a terrible design flaw, that unfortunately, PHP invites).  The PHP script failed, as expected, because there is no class 'Constants' in the script.  In the course of creating the failure message, PHP generated a response that contained single quotes.  These single quotes collided with the single quotes that are explicitly coded in the location.href attribute.  Complex interaction, not what you wanted, but expected behavior.

You could get the same sort of effect with something like this:
<input id="btnDashboard" type="button" value="Back To Dashboard" onclick="location.href = 'whatever';" tabindex="17" />

Open in new window

In that script you would be able to use the browser viewport to see the button and the browser would not be confused about the quotes inside the HTML tag.

To fly up to the 50,000-foot view, here is what you might consider.  PHP is used to run software on the server.  It generates the HTML document and sends the document from the server to the browser.  Then the server disconnects and "goes away."  The browser renders the document it received in a client viewport.  The server sits and waits for a request.  All of this is covered in the articles.  The design flaw that leads to confusion arises when an HTML document and a PHP script are mixed together in a "spaghetti code" mess.  This is one of the worst ideas in the history of PHP, but it's an unfortunate part of the language legacy, and we can't get rid of it - we can only learn of the risks of this kind of spaghetti code and avoid them as we go forward.
0
Dave BaldwinFixer of ProblemsCommented:
You do not have to wait any time at all to see if that error occurs in the current page.  If it occurs, it will occur when you first request the page and you will be able to see it in the view source.  If you see the correct info in the current page and you get that bad URL after clicking, the only way that that can happen is if the destination page is changing it and doing a redirect.  If that is the case, you probably don't have to wait 3 days for that either.

The internet and web page and web browsers in particular, operate on a very simple principle.  A client (usually a web browser) sends a request to a server and the server sends a response back to the client.  Stop.  Nothing more until the client sends another request to the server and the server sends back another response.  Stop.  Even pages that appear to be changing all the time are actually working on the same principle except they are using AJAX to make the requests and put the responses on the page.
0
elepilAuthor Commented:
Dave, you said:

You do not have to wait any time at all to see if that error occurs in the current page.  If it occurs, it will occur when you first request the page and you will be able to see it in the view source.

Finally we are on the same page! As I said, it works 100% of the time when I'm working on my application. I repeat, it works 100% OF THE TIME. Somehow, both you and Ray keep saying that my page wasn't rendered correctly when it was sent back by PHP in the first place; if that were the case, it would fail 100% of the time, but that is not the case.

Read the following, as this is actually what happened:

I was testing my application with the Opera, IE, Firefox, Safari, and Chrome. Everything is going perfect. Then I decided to call it a day and left the browsers open, each one of the at various different pages, not on the same one. Remember, they were all working PERFECTLY, and I left them all at different parts of the application. I didn't touch them until 3 days later. When I got back and tried to click one of the links (which I expected to work as usual), I instead got the problem I described. I tried to click a link on all the other browsers (where the link depends on where I left them at), I got the same error.

So what you're claiming that PHP is somehow not sending back a correctly rendered page where my links are somehow still PHP scriptlets is incorrect, or it would NEVER have worked. Now as I said, I didn't do a View Source on the browsers before clicking a link, but I will do so next time, but I seriously doubt that's the cause of the problem.

I cannot believe I have spent most of my time on this issue trying to explain to responders what the problem is.
0
elepilAuthor Commented:
Ray,

Like Dave, the scenario you are describing would have resulted in my page NEVER to work. Please read the last response I gave Dave Baldwin, as I described the actual sequence of events.
0
Ray PaseurCommented:
I guess I am still mystified.  Why are you worried about this at all?  Why not just restart the server, fire up a new browser and get back to work?  Nobody does this three-day exercise in "real life."  Your clients will never experience something like this.  It's academic, or as some might say, "the wrong question" to worry about.  Maybe better to figure out a good strategy for avoiding spaghetti code!

If you can show us a reproducible error that we can copy, install and experience, I'll be glad to help, but I haven't really got the capabilities to create a dedicated test-bed for a three day latency, sorry.
0
Dave BaldwinFixer of ProblemsCommented:
Since HTML and PHP don't work that way, I have to say you are wrong about your assumptions.  The only other possibility is that your 'target' page is doing a redirect incorrectly.  There is no way that your links in those pages are going to change during that 3-day period without something else going on.
0
elepilAuthor Commented:
Dave, you said:

There is no way that your links in those pages are going to change during that 3-day period without something else going on.

Again! We're on the same page!! Hurrah! The links, once rendered by PHP and sent to the browser, SHOULDN'T change, unless there's a timer running that periodically refreshes the page.

We can keep saying "this can't be ... that can't be", Dave. But the fact remains, this issue happened to me and I am perplexed. That's why I asked prior if PHP or Apache might have a timeout of some sort, because something might've caused the Apache server to refuse to run the PHP interpreter to my domain.
0
elepilAuthor Commented:
Ray, you said:

Why are you worried about this at all?  Why not just restart the server, fire up a new browser and get back to work?  Nobody does this three-day exercise in "real life."  Your clients will never experience something like this.  It's academic, ...

Ray, that's where you would be dead wrong. My client's employees are extremely notorious for leaving their browsers in the middle of an application then leaving for the weekend, sometimes a long weekend. That is the reason why it is important for me to at least find a graceful way to recover from this, or it will make me look bad as a professional developer.
0
Dave BaldwinFixer of ProblemsCommented:
why I asked prior if PHP or Apache might have a timeout of some sort
If the link is good, it is simply a new request.  No time-out will produce the result you have seen.  It has nothing to do with Apache or Sessions.  Somewhere, somehow, a link was created that was not formatted properly, either in the original page (which you would see in "View Source") or on the target page in a redirect.  If you have been working on those pages, you may have fixed it already.

Note that one of the advantages of using multiple browsers is that each one will get it's own session so it does not interfere with what is happening in the other browsers.  You might be able to take advantage of that to do some troubleshooting.  If you can get the 'original' page to record something in a database that you can check from another browser, that might help you figure out what is going on.  It would have to be a database because the different sessions can't 'see' each other.
0
Ray PaseurCommented:
My client's employees are extremely notorious for leaving their browsers in the middle of an application then leaving for the weekend, sometimes a long weekend.
Good thing they don't work in the defense industry.  One stunt like that and they'd be under investigation for (potentially criminal) security violations!  

I think we're still at the "my car won't run - what's wrong" level on this question.  If we can get something that gives us the SSCCE, we may be able to help move the ball forward.  But I just don't know how to help when everything I know is "dead wrong" and we can only get vague descriptions without any reproducible objective evidence.  Please isolate the problem, show us the code to produce the failure, and we'll try to help you understand what's going on.
0
elepilAuthor Commented:
I found out what the problem was, hehe. I had a .php file that I require_once called sessionCheck.php which checks if the session has expired. And if it has, it redirects to my login.php.

So it's already a PHP file, and I had this:

redirect('<?php echo Constants::URL_LOGIN ?>');

Open in new window


It should be:

redirect(Constants::URL_LOGIN);

Open in new window


So this happens only when the session has expired, which can take an extended period of time, that's why it didn't occur until days later.

Ray's answer was flagged as best only because he responded first, but both of you tried equally hard and well. As usual, you both have my thanks.
0
Dave BaldwinFixer of ProblemsCommented:
Glad you found it and that makes sense.  It was in a string where it wouldn't be processed as a PHP statement but just as a string.
0
Ray PaseurCommented:
Now that we know what caused the problem, you might find this article helpful.  It does not rely on any special checks - it just uses the PHP built-in functionality - simple and safe.
http://www.experts-exchange.com/articles/2391/PHP-Client-Registration-Login-Logout-and-Easy-Access-Control.html

You might also want to "lint" your project to see if you have <?php in any line of a script code other than the first line.  If you do, it's either an error like this one, or there is some PHP embedded in HTML (an anti-practice).

Best of luck with the project, ~Ray
0
elepilAuthor Commented:
Ray,

In the link you provided, I saw this code:

// CLEAR THE INFORMATION FROM THE $_SESSION ARRAY
$_SESSION = array();

// TELL PHP TO ELIMINATE THE SESSION
session_destroy();

Open in new window


Why would you need to assign an empty array to $_SESSION if you're already going to do a session_destroy()?

I guess different people will do this different. I have a Log Out link on every page of my application, and when the user clicks it, it redirects them to login.php. At the very top of login.php, I have this:

/* When the user clicks the "Log Out" link from the other pages, they are 
 * redirected straight to this login page where the session is destroyed. */
session_start();
if (isset($_SESSION['user'])) {
    /* If 'user' is in the session, destroy the session */
    session_destroy();
}

Open in new window


Good thing I don't have much of any cookie to worry about since I only store the username which I use to pre-populate the username field during login, and I don't ever want to delete that.
0
Dave BaldwinFixer of ProblemsCommented:
Why would you need to assign an empty array to $_SESSION if you're already going to do a session_destroy()?
Because as we have discussed before, the $_SESSION data in the files on the server will rarely be erased immediately.  That only happens when PHP does it's garbage collection.  If you want the data to disappear when you 'destroy' the session, you have to clear the data from the array (which then gets saved to the the disk as an empty array) before you do session_destroy().  After you do session_destroy(), the session_id is gone and you can't access the previous $_SESSION data.

This page shows the proper procedure for doing session_destroy(); http://php.net/manual/en/function.session-destroy.php
0
elepilAuthor Commented:
Ah, thanks for the clarification, Dave.
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.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.