web notes - a blog

Using a site’s home page as an error document is a good way to prevent people and ‘bots from learning more about the site architecture. Routing all error requests to the home page, or some other page, will reduce information leaks, such as ‘file not found’, ‘access denied’, and script failures which could display error information.

It is important to monitor the server error log to see what errors are occurring. Be sure there is a robots.txt file, even if it is empty. Check the log and stats to see what files people are requesting.

Be careful not to confuse legitimate users - if you remove pages or update content frequently, you may want to use 301 redirects for those pages to alert site visitors and search engines of the change.

The Wicked Good Gallery grew from an idea mentioned at http://w3schools.com/forum and discussions with the people at http://lilyclaireart.com.

The challenge was to build a gallery application that would allow site visitors to view and purchase artwork and be very easy to administer.

The gallery offers two viewing modes, navigation through the thumbnails at the top of the page, and a slide show. The thumbnails are limited by the width of the page, so not all thumbnails may be displayed. Arrows are used to indicate additional images earlier or later in the list. Clicking on a thumbnail displays a larger image, along with the associated HTML. The slide show hides the HTML and centers the image, then loops through the images to display all the images of the gallery. It’s as if the site visitor is walking through the gallery, looking at artwork.

Administration is through SFTP/FTP/SCP. The person running the site creates a directory, named for the image, and places the original image .jpg in it, as well as free form HTML. When the site loads the next time, it will find the new directory, check for a thumbnail and detail image, and create them if necessary. When site visitors click on the thumbnail, the HTML will be displayed with the image.

With respect to SEO, each image is represented with a dedicated URL. The artwork’s name is used as the title, and the more text in the HTML for that image, the better.

All requests into the application are routed through a single file. If the requests map to an image, the appropriate artwork is displayed, otherwise, the home page, or contact page is shown.

Strategies I used to make a simple web application adapt for both desktop/laptop and mobile browsers:

• Read http://docs.blackberry.com/4305/. Key elements - keep the page simple, don’t assume you’ll have CSS, don’t assume you’ll have scripting or images.
• Validated the pages for both XHTML Basic and mobileOK up at http://w3c.org
• Used user agent detection which relied on strings posted at http://en.wikipedia.org/wiki/List_of_user_agents_for_mobile_phones. Preserved an identifier to allow a custom CSS file for devices. Test for the presence of the custom CSS file, thus, new ones can be added later.
• Tested the BlackBerry and Android using simulators.
• Chose to use a single script that adapts to the user agents, rather than separate dedicated files, since the basic processing is the same regardless of device.
• Used custom javascript for different devices to change the name of the button. The button’s name changed from ‘noscript’ to ’script’ if the scripting executed. This worked better than using the noscript tags.
• Used FireFox for development, it’s much easier to work with than a mobile simulator or device.
• Used the Apache access_log to get the UserAgent string (you could also use PHP’s $_SERVER[’HTTP_USER_AGENT’] or the equivalent), with cURL to get the page Google delivers for Androids. This effectively allows you to view the source for a mobile device, and it’s much easier on a lap or desktop.

This reduces the opacity of the logo to 10%.

convert logo.png +flatten -alpha on -channel A -evaluate set 10% +channel opac.png

There is an RPM for Firefox 3.6.4 for CentOS. It prevents issues with SELinux which arose when version 3.6.3 was installed as described in the ‘OLD POST’ method and then upgraded to 3.6.4.

That said, 3.6.6 is now out, however, I don’t think there’s an RPM for CentOS, yet.

— OLD POST —

Last night, Google refused my search requests, claiming that something was making too many requests. Since it was late, I shut off the laptop. This morning, I Googled for information and found http://www.digitalspy.com/forums/showthread.php?p=40231435, which is exactly what happened to me. Next I found http://www.fortiguard.com/encyclopedia/vulnerability/firefox.centos.security.update.cesa-2010-0112.html, which led me to http://www.mozilla.com/en-US/products/download.html.

After a bit more surfing, I landed in http://www.esecurityplanet.com/features/article.php/3881621/Security-Firm-Finds-Gaps-in-Popular-AV-Software.htm.

I downloaded FireFox 3.6.3 to my desktop and untarred it. I tried to install it ‘properly’ such that all the users on the laptop would be able to use it, but that didn’t work out. Eventually, I used the package manager to remove the old version of Firefox (3.0.18), changed into the firefox directory, ran updater, then ./run-mozilla.sh ./firefox and it worked. It’s not ideal, but it is running. There’s only one user on this laptop, it’s me.

Several days later I had the same problem. On a hunch, I removed a FireFox toolbar that was displaying the Google page rank. The next response from Google asked me to enter a CAPTCHA code, and then, everything was fine.