7 posts categorized "siteadmin"


Perils of Production: Moving Content Between Staging and Production

A well known children's television web site recently went live with a new service for kids. As part of the login account creation process, a parent or guardian needs to fill out a basic sign up form (which only required an email address and a password). An email verification gets sent to the email address on record and, once verified by clicking the embedded link in the message, the account creation process setup is complete. This is all a fairly standard practice. All kinds of sites have been doing this for years but when my wife started the sign up process, she kept getting a basic authentication sign-on message box when trying to complete the verification process and nothing she tried would work to sign in. She would try multiple types of email accounts and browsers over the course of the next few days to no avail and wound up walking away extremely frustrated.

After thinking about this off and on for a day or so, if finally occurred to me that maybe the problem wasn't with the site but with the link that was embedded in the verification email. Guessing that the site that was embedded in the email verification was a staging site, I simply copied and pasted the URL in the browser and swapped the hostname with the regular site address and everything worked great. Had the embedded URL been obvious like "staging.testsite.com", it probably would have occurred to me sooner but the site name wasn't that obvious. Now my wife thinks I'm a hero and my youngest kids get to think for another few days that their Dad can do anything.

Sending out the wrong email address in a link to customers and potential users though is not a unique problem. I've seen it happen many times over the years with several companies that I've worked for and it got me thinking that the process of moving something between environments is not really something that I've seen automated well--some manual intervention is always required and it is this manual intervention that has the most room for error. One can certainly mitigate errors by using relative URLs as much as possible everywhere but in customer communications and when switching between secured and unsecured modes on your sites, absolute URLs become a necessity.

I'm very interested in hearing what other folks have done when it comes to moving content between environments and making sure that all the URLs and hostnames stored in application configuration files point to the right places.


Custom Errors in Apache

I came across this in the httpd.conf on the apache web servers for a major web site of ours.  The initial configuration had been hosted at a third party facility, then was brought in-house when the parent company purchased the firm that initially developed the web site.  Below is an example of the custom error page handler from this site:

ErrorDocument 404 /custom_errors/404.html
RewriteRule /custom_errors /webapp/path/404.html [R]

The first line sets the 404 custom error page to a page running on the local server.  The rewrite rule then issues a 302 redirect to the browser and tells the browser to pull the page from the web application path, (even though the page actually exists on the local filesystem as /custom_errors/404.html).  The only reason why I can think that the developer wanted this done was so that the page appears to be getting delivered from the same web application path that everything else was delivered from.

The main problem though with this kind of approach to custom error page handling is that you lose the 404 response code.  If ErrorDocument is set to 404 with a custom error page, apache still responds with a 404 - Not Found message but if you then issue a rewrite, then your browser receives a 302 redirect followed by a custom error page delivered with a 200 OK status.  This ultimately means that your custom error pages can get listed in search engines results pages (SERP).

We had one of these for 503 status codes too and it sure was interesting searching on Google for "name of the site +service interruption" and seeing how many valid links wound up getting listed with the "We're sorry. We are experiencing a service interruption" description.

The thing to keep in mind for web site administrators is that just because developers know ASP or JSP or whatever really well, it does not mean that they necessarily understand how the web and browsers work. If you see a custom 404 errors implemented as a jsp page, make sure that at the top of the source of that jsp page you see something like:

<title>404 - Not Found</title>
<% response.setStatus(404); %>

If it isn't there, get someone to put it there.  Otherwise, your business partners might wind up asking you why they are seeing the site's custom error pages showing up in Google's search engine result pges.


Another Useful iRule::Redirect based on client IP

Another short but useful irule I put together for those times when a release is going in and you want your external customers to get redirected to a maintenance page while your internal testers can still get into the site in order to validate the release.

if { ! ([HTTP::uri] contains "/path/to/custom/errors")}{
if { ! ( [IP::addr [IP::client_addr] equals]) }{
HTTP::redirect https://www.somesite.com/path/to/custom/errors/maintenancePage.html

This irule redirects customers unless their client IP matches an internal subnet. The first line prevents a redirect loop from occurring. Whenever we commit a release, this rule gets enabled and works without a hitch. However, because we have lots of internal subnets scattered all over the world and with different partners, continually adding

"or [IP::addr [IP::client_addr] equals X] or ...."

statements can get tedious. So another alternative is to create a class of internal subnets and if the address does not equal one of those internal addresses, redirect.