Blog

When you find trouble, let the site operator know!

This weekend, there was a “brute force attack” against WordPress sites around the world, including a large number of sites at the ISP who makes this very site available to readers of our book, and other interested members of the online community. This ISP — who shall remain un-named for those of you not savvy enough to use nslookup and ip2location.com to figure out who it is (hint, hint) — got slammed enough by brute force password guessing attempts (which failed against our site, thank goodness) that this attack translated into a denial of service. In English, that means the site became unavailable: in fact, it showed a 404 error when access attempts were made.

Website goes by-by, thanks to botnet attack.

Website goes bye-bye, thanks to botnet attack.
[Image Credit: Shutterstock 133546157]

Gretchen K. came to the rescue, in the form of an email that read “Try to access your site, and get a 404 error instead.” Because neither Jeff nor I make our livings from this site, we don’t monitor it extremely closely, so this e-mail actually gave us the warning that something was wrong, and needed to be addressed. My first response to Gretchen was an email that said: “Thanks for letting us know. Sorry for the inconvenience. We’ll get it back up as soon as we can.” My second response was to send Jeff an e-mail asking him to contact the ISP to find out what was up (he handled that responsibility for the 7th edition of the book, so I gladly punted to him in this case). Next, I sent another e-mail to Gretchen K. that said “Repairs are underway. I’ll be back in touch when the site comes back up.” A few hours later, I did just that, and the site has stayed up ever since.

What should readers of HTML and CSS For Dummies take away from this exchange? Here’s a list of take-aways to ponder as you work on and maintain your own Websites:

  1. Always respond to anyone who notifies you about problems as quickly as you can, and keep them updated on status as things progress. I always apologize for any frustration or inconvenience the person who’s been kind enough to tell me I have a problem may have experienced, especially if they seem unhappy about the situation.
  2. Try to diagnose and fix site failures with your service provider right away, understanding that it may take time to get back in business or recover from an outage. Keep tabs on status throughout (in this case, that meant checking the URL for the site every 15 minutes or so; monitoring tools for this kind of thing are also available, so if you do make your living from a Website – or your employer operates one as an official online presence — you’ll want to invest in some kind of web site monitoring service to keep close tabs on any such sites 24/7/365).
  3. Fix any problems the site may have as quickly as possible (which could range from typos or minor formatting errors, to wholesale reworking of content items). Keep anyone who’s expressed interest informed about status periodically as well. Be sure to send a message (or tweet, or whatever) as soon as the problem is fixed, or the issue has been addressed.
  4. When the outage is over or the problem is fixed, conduct a post mortem. Try to figure out what went wrong and why, and how you might keep the same thing from happening again. In this case for example, experts recommended installing a plug-in named “Limit Logon Attempts.” This helps fend off the advertised attack by permitting only an admin-assignable number of password guesses before the attacker has to break off, and the originating IP address gets locked out. This kind of thing effectively foils most brute force password guessing attacks.

Of all these take-aways, the most important is the one where you communicate frequently  and reliably with those who communicate with you about your Website. This goes beyond simple courtesy — in itself no bad thing — to assert and reinforce your conviction that people who care enough about you to tell you there’s some kind of problem or issue that needs to be addressed also deserve your continuing communication and respect. Follow-up is key! Put this lesson to use, and you’ll grow your user base even if (or I really should say “when”) you make the occasional mistake, or experience the odd Internet hiccup, glitch, or outage. It happens to all of us, but it also presents an opportunity to provide a positive customer or user support experience. Don’t miss that opportunity, please.

How to grab the 404 (Page Not Found) Error and Make It Your Own

From time to time on visiting just about any website, you’ll occasionally click on a bad link or make a typo when entering a URL, which elicits the famous 404 error. The HTTP error codes are well-defined, so you can always look this stuff up for yourself if you like. The W3C defines the HTTP status codes that drive all this stuff in RFC 2616, Section 10. Section 10 is labeled “Status Code Definitions,” where you’ll find this text for the 404 error code:

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

The key usually is that “…no other response is applicable,” simply because the server has no idea at all about what happened to the page. The generic error page that often appears when this happens can be less than informative, inspiring, or amusing. You can always test your own site by deliberately typing in a bad URL to see what happens. Thus, when I deliberately type http://www.dummieshtml.com/nofileexisting.html into this very web site, here’s what shows up in response:

A generic error message, but the site's CSS ensures it's nicely packaged.

A generic error message, but the site’s CSS ensures it’s nicely packaged.

You can do better than this, if you like, but it will take some extra work. So first, let me show you some good illustrations of why you might want to do this, and then provide some pointers to potential explanations as to how you might go about making something cool, funny, or more interesting visible when your users trigger the 404 error code.

Giving You Some Good 404 Illustrations

I got the idea for this blog post while chunking through LinkedIn this morning, when I stumbled across this news item there:

Business Insider's Top Picks for All-Time Best 404 pages.

Business Insider’s Top Picks for All-Time Best 404 pages.

These are already pretty funny, with some verging on the hysterical and others on the “Huh?” side of humor. But I’ve been around the Web long enough myself to recognize this as a pretty well-established genre of “geek humor,” as a well-crafted Google search will instantly illustrate. Here’s list of links to some other yuck-worthy compilations of 404 humor:

Run the Google search yourself if this isn’t enough yucks to motivate you to check out the next step — there’s plenty, plenty more where those items came from. As for the purposes of this blog post, I’m going to assume you’re convinced, and are indeed ready to read on — so keep going, please!

How to Customize Your Own 404 Page

A wise man once told me, and I never forgot the veracity of his observation that: “The answer to any good question always beings with the same two words — namely ‘That depends…’” In the case of customizing the 404 error page, you must first and foremost understand that you’re seeking to customize the behavior of the Web server that’s serving up your pages. There’s a great tutorial on how to do this in general at thesitewizard.com, so I won’t treat you to the whole thing here, but I will share three important observations from that source:

  1. You may not have the ability to customize your 404 page, or other error pages. Your hosting provider must make this facility available to your Website, and most of the really cheapo providers don’t do this simply to save a penny here and there.
  2. You will probably need to customize your .htaccess file to, as Christopher Heng puts it (he’s the author of the afore-linked 404 tutorial I’m summarizing here) to add an error directive entry into a special file that will tell the server what to do when it encounters a specific HTML error code. For the 404 error, for example, it will typically consist of a line of text that looks something like this: ErrorDocument 404 /notfound.html. Translated into human-intelligible pseudo-code this means “Server, when you encounter a 404 HTTP error, find and display the file named notfound.html in the requester’s Web browser.” On the other hand, your site operator may have already done this as part of their basic server set-up, in which case you need to find the file referenced in that errordocument statement, and start customizing (this is described in very broad terms in step 3 that follows).
  3. Creating an error document file means building the Web page you wish your users to see if and when your hosting server encounters an HTTP 404 error. You can build all the great graphics and text that you like, but you should also consider Heng’s advice about what a good 404 page also contains, including a link to a search engine if your site has one (as we do on our 404 page displayed above) along with a link to the site’s home page, a site map, a list of frequently-mistyped URLs for your site with links to the correct pages, and other navigational aids your site might also present to users (like the navigation tabs at the top of the 404 page from our site, for example).

Indeed a good 404 page can be funny and interesting, but it should also do its most important job — that is, help users figure out where they should go next, once they reach a dead end in your pages, for whatever reason. That’s why I’m going to work with Chris Minnick, my co-author for the next edition of our book, to add a text input field to our 404 page that reads like this:

“Please take a minute and tell us what URL you entered when you wound up on this error page. You can use the Back arrow (or backspace key in most Web browsers) to return to the previous page, copy the link that caused the error, and paste it here to help us out. If we can fix it we will, and if it’s a recurring error, we can make it easier for others to get where they really want to go in the future. Thanks!”

Interesting e-mail exchange: HTML vs XHTML

It’s not really a wrestling match, but it is something of a face-off:

html401VSxhtml

Email 1:
Dear Mr Noble:

I am writing a research paper on the difference between HTML and XHTML along with the advantages and disadvantages of the two. I am asking for your opinion because I have learned quite a bit about the languages reading your book HTML, XHTML & CSS for Dummies. From your bio in the book it seems you have a lot of experience and the book itself only proves that. So I was wondering, what is your opinion on HTML vs XHTML? Which is most efficient? Which is, in your opinion, the “best” and why?
 

Egad! We’ve Been Hacked

Wow! I hate to admit it, but we’ve found — and cleaned up — evidence of a WordPress-specific attack on this very Website recently. The signs showed up first in descriptive text about the site on Facebook, but then this morning we got word from one of our readers that active links to various payday loan sites were showing up through our home page. And sure enough when I went to “View Source” on that page, here’s what I found:

<p>Within the basic facts including payday cash than payday loanspaperless payday legal citizen of fraud or able to expedite the present valid source however there has <a href=”http://m*rtg*gebankpaydayloans.com/”></a> poor of bad credit borrowers who says it take on what faxless payday personal need some boast lower than average credit this occurs payday advance. Problems rarely check on it at cash advance <a href=”http://ch**pcashadvanceonline.com/” title=”cash advance”>cash advance</a> your will most needed. Low fee for school or worse payday loans <a href=”http://p*yd*yloanchannel.com/” title=”payday loans”>payday loans</a> you gave the country.  …other similar text removed for brevity’s sake, asterisks added to URLs to prevent blockage or blacklisting…</p>

Jeff jumped up to the site and killed the offending injection into one of our primary header files that was causing the problem, and then turned up this fascinating article from Sucuri entitled “Common WordPress Malware Infections” from our friends and colleagues over at Smashing Magazine. We’ve put the Sucuri SiteCheck facility to good use to produce the following results report, too:

After some clean-up, a clean bill of health results.

After some scrubbing, a clean bill of health.

All of this information is presented to make some important points about web site security:
1. When you turn your platform over to a third party like WordPress you inherit all of its security weaknesses.
2. Keeping your site up to date includes keeping the platform up-to-date and secure, as well as the content.
3. Monitoring site security is easier to do that I originally thought, but also more important than I had thought as well (I have no trouble understanding why site operators pay for multiple daily security checks to limit exposure to exploits should they occur).

If they can hack us, they can probably hack you, too, so you’ll want to take steps to prevent such things from happening. Be sure to talk to your service provider about how they secure your environment, and ask them what steps you must take to help secure your website, too. To do otherwise risks embarrassing inclusions of unwanted content on your web pages (which is what happened to us) as a sort of “best case of the worst case.” But it could also result in users downloading malware when they access your pages, which in turn will either cause them to stop visiting your site (bad enough already) or make search engines like Google or Bing blacklist your URLs as malware infected (if you can’t show up in the engine’s search results, potential visitors can’t find you, which is an instant “kiss of death” for modern websites and thus a “worst case of the worst case” scenario).

–Ed–

So long, Jeff! Next, say “Hi,” to Chris Minnick

Hello! Ed Tittel here, with some interesting news about the next planned edition of our book:

I’m very sorry to  report that my co-author and collaborator, Jeff Noble, has decided to drop out of the upcoming revision to our book. We’re probably going to call it HTML5 and CSS3 For Dummies, and it’s going to be a complete rework to get everybody up to speed on HTML5 markup and some of the HTML5 canvas capabilities, along with coverage of Cascading Style Sheet (CSS) markup with an emphasis on CSS3 stuff. Jeff, however, is too busy with his job as Director of Product Design at CA Technologies (the huge conglomerate formerly known as Computer Associates) to bite off and chew upon the upcoming edition. I’m sad about this, because Jeff has been a great influence on and driver for the two previous editions of HTML, XHTML, and CSS For Dummies, sixth and seventh editions, and had already started to gear up with me to get going on the next edition of the book. But he has wisely decided to opt out of this project because he needs to concentrate on his real job, and keep his many and mischievous minions in line.
Read More »

HTML & CSS From Around the Web on December 28, 2012

Check out these cool web design links from around the web!

HTML & CSS From Around the Web on December 21, 2012

Check out these cool web design links from around the web!

HTML & CSS From Around the Web on December 14, 2012

Check out these cool web design links from around the web!

HTML & CSS From Around the Web on December 7, 2012

Check out these cool web design links from around the web!

HTML & CSS From Around the Web on November 30, 2012

Check out these cool web design links from around the web!

All Images and Content © 2013 HTML, XHTML and CSS for Dummies, 7th Edition. All rights reserved.