An issue with authentication, which was reported this afternoon, was preventing users from signing in. We can see how preventing users from signing in might be bad for business. So, we promptly corrected it.
The issue involved a few misplaced lines of code that break the user out of SSL after successful authentication. The code should have been moved to it's new home with a larger segment of code, but it's such a small snippet of code that it was simply overlooked.
For those interested geeks:
if ($signin_event == true) {
make_secure(false);
}
After successful authentication, the
$signin_event flag is set to
true. After the core signin routines are called successfully, the
make_secure() method is called with a value of
false, returning the user to the "non-secure" version of the site. For the production version of the site, this means redirecting the user from an
https URL to an
http URL.
However, the
redirect() method used in this
make_secure() method outputs the HTTP
Location header with some informational HTML and then
terminates the script. And this was occurring before the session cookies were being sent — not a problem for the staging version of the site, which requires no redirection when
make_secure(false) is called. For the production site, however, this was preventing the cookie headers from being sent. (One might say that the
$signin_event didn't
really happen yet :) )
We failed to detect this, because we already had the session cookies from our previous sessions, and it really didn't seem like a game-changing update. So, for ourselves and anyone else who happens to be human, here are some web development reminders:
- Keep the "subtle" differences between yours staging and production environments in mind. They start to seem trivial after awhile, and they're easy to forget. But, minute differences can be crippling.
- Test authentication, session, and cookie-related updates with a clean cookie cache. This is most important when you're playing with cookies. But, anything that touches "the session" in a unique way should probably be tested from a blank state.
- Always keep in mind which methods terminate the script, blocking other important actions. In the very least, be ready to check your methods if you have any doubts. It can be difficult to debug strange behavior if you've totally forgotten than redirect() terminates execution instead of returning. One might say that redirect() should never terminate execution anyway. I didn't necessarily like implementing it that way, but there's good rationale for it in this case.
- Be careful when you copy and paste! It sounds like a simple and stupid reminder. But, I've been involved in web development for years, and I still forget to fully examine my context when I'm tired, bored, under-caffeinated, or simply doing something tedious.
This is by no means an authoritative, comprehensive list to avoid mishaps. It's what came to mind while I was writing this update. So, there you have it.
If you have any tips you'd like to share for avoiding mishaps like this, feel free to comment.
