Blank Pages and Expiring Cookie PHP Help

At some point as you’re trying things out, you might get a strange response, You enter in signin.php in your URL bar, you press enter, and you end up with a blank page, like the one in Figure 13-5,



You try it again. You try to reload. You try to clear your cache. Nothing! Finally, you restart your browser, and things start to behave. But no sooner have you signed in through Signin.php than it’s happening again. What’s up?

Actually, this is a sign that things are working correctly. Remember that in your script, the first conditional checks for a cookie:

// If the user is logged in, the user_id cookie will be set
if (!isset($_COOKIE[‘user_id’])) {

If this cookie is set, the script jumps all the way down to this bit at the bottom of your file:

} else {
// Now handle the case where they’re logged in
// redirect to another page, most likely show_user.php

There’s nothing there, so you get a blank browser. You can fix this (kind of) by setting up a default action for users who are sent to signin.php and yet are already logged in. In fact, it’s the same thing you did earlier for a login: redirect them to show_users.php.

} else {
// Now handle the case where they’re logged in
header(“Location: show_user.php”);

Now, there’s no more blank screen. Your Show_user.phpl) script picks up on the “user jd” cookie and shows the currently logged-in user. Good, right?

Well, sort of. It still leaves you in an endless loop. It’s just that now you’re looping on the nice looking show_ user.php rather than a crummy-looking blank page. You’ll need to completely close out your browser to stop the madness-which is exactly as it should be. Just as when you logged in via HTTP authentication, logging in and setting a cookie sets that cookie to exist until the browser is closed.

If you need to get out of this loop, just close your browser. Be sure to close the program, not just the current tab or window. This will cause a cookie that has a default expiration value to expire .

To set the cookie to last longer (or shorter), just pass a third parameter to setcookie. That third parameter should be expressed in the number of seconds from what Unix and Linux systems call the epocr, January 1,1970, at 0:00 GMT. You usually pass in time, which gives the current time-also in seconds since the epoch-and then add to that. Thus, time 0 + 10 would be 10 seconds in the future, as reckoned from the epoch.

Here are just a few examples of setcookie with a set expiration time:

// Expire in an hour (60 seconds * 60 minutes = 3600)
setcookie(‘user_id’, $user_id, time() + 3600);

// This actually deletes the cookie, since it indicates an
// expiration in the past
setcookie(‘user_id’, $user_id, time() – 3600);

// The default: expire on browser clo~e
setcookie(‘user_id’, $user_id, 0);

You can also supply a time via mktime, which takes an hour, date, second, month, day, and year, and returns the number of seconds since the epoch (again); therefore

setcookie(‘user_id’, $user_id, mktime(o, 0, 0, 2, 1, 2021);

sets a cookie to expire on February 1, 2021, GMT.That’s a little far away, wouldn’t you say? In general, the default value is perfectly reasonable. Most users are comfortable signing in again when their browser closes. In fact, many users would ‘be comfortable with their login lasting on and on, potentially in perpetuity.

Close your browser, which will terminate your cookies, and open signin.php again for some more improvement.

Errors Aren’t Always Interruptive

At this juncture, you have a potential error with which you must deal: the else that’s run when the user’s user name and password don’t match that which is in the database:

if (mysql_num_rows($results) == 1) {
// set a cookie and redirect to show_user.php
} else {
// If user not found, issue an error

Your typical error handling so far has been via handle error. But that’s no good; you don’t want to short-circuit the login process by throwing the user out to an error page. She would have to get back to the login page, try again, and potentially go to the error page yet again.

What you need is a means by which you can show any errors without interrupting the application’s overall flow. When something goes badly wrong, handle_error makes perfect sense; a major error deserves to interrupt your application. But here, you need a non-interruptive way to show errors.

You GO in fact have another way to show errors: the page_start function in View php. Right now, you’re calling this function in signin.php but without anything a part from the page title:

page_start(“Sign In”);

Back in view.php (page 379), you can see the complete set of arguments this method takes:

function page_start($title, $javascript = NULL,
$success_message = NULL, $error_message = NULL)

Normally, you’ve been passing in any request parameters as the values tor $success _messageand $error _message, but that’s not a requirement. You can create a new variable called $error _message, fill it with text as your script progresses, and then hand it off to page_start as the HTML output commences.

Here’s what you need to add:

Logging In the User

Now visit signin.php (or index.html and click the Sign Up button). Uh oh! Figure 13-6 reveals there’s still a problem somewhere.



This predicament is typical of application work. You take a function you wrote ages ago-the code in view.otn: that shows an error, in this case-and then use it in a different way later. That’s when the bugs appear.

In this case, the problem is that you’re calling page_start with $error _message, but in some cases, $error _message is blank. It’s an empty string, …., so nothing should be shown. Check out and find dispIay , message:

function display_messages($success_msg = NULL, $error_msg = NULL)
echo “<div id=’messages’>\n”;
if (!is_null($success_msg» {
display_message($success_msg, SUCCESS_MESSAGE);
} .
if (!is_null($error_msg» {
display_message($error_msg, ERROR_MESSAGE);
echo “</div>\n\n”;

In this case, $error _message Isn’t null. It’s an empty string that the if block lets pass, causing a blank error message to appear in a red box: not so good.

The fix is no problem, though. Simply determine whether $error _message is not null, and whether it has a length greater than 0. While you’re at it. make the same improvement to the handling of success messages:

function display_messages($success_msg = NULL, $error_msg = NULL)
echo “<div id=’messages’>\n”;
if (!is_null($success_msg) && (strlen($error_msg) > 0» {
display_message($success_msg, SUCCESS_MESSAGE);
if (!is_null($error_msg) && (strlen($error_msg) > 0» {
display_message($error_msg, ERROR_MESSAGE);
echo “</div>\n\n”;

Now you should see a proper sign in form, as demonstrated in Figure 13-7.

Try to enter an incorrect user name or password, and you should see a nice, clear error that doesn’t pull you out of the login process. Figure 13-8 shows this message. Better still, your user can immediately re-enter her information





Posted on January 14, 2016 in Cookies, Sign- Ins, and Ditching Crummy Pop-Ups

Share the Story

Back to Top
Share This