Website testing with SortSite

SortSite is a popular desktop software for testing of web applications for broken links, browser compatibility, accessibility and common spelling errors. It is also available as a web application known as “OnDemand“.

You can generate a free sample test of your website at:
http://try.powermapper.com/Demo/SortSite

REFERENCES:

Security through obscurity – hiding your server version information

I’ve recently spent a lot of time reviewing the OWASP documentation, and (like many corporations) realized that I’d neglected to keep up with this configuration item.

By sharing the exact version of each piece of server software you are using, “hackers” are able to quickly identify unpatched systems and their known vulnerabilities.

To make their work harder, there are a few simple steps that the server admin can take to remove this information from the HTTP Headers and error pages.

Apache HTTPd:

  1. sudo vi /etc/apache2/conf-enabled/security.conf
  2. Add:

    ServerTokens ProductOnly
    ServerSignature Off
  3. If using virtual hosts, add the following to each one:
    ServerSignature Off
  4. sudo service apache2 restart

Apache Tomcat:

  1. vi /opt/tomcat7/conf/server.xml
  2. Find the <Connector > entry and add:
    server="Apache"
  3. cd /opt/tomcat7/lib
  4. mkdir -p org/apache/catalina/util
  5. vi /opt/tomcat7/lib/org/apache/catalina/util/ServerInfo.properties
    server.info=Apache Tomcat
  6. sudo service tomcat7 restart

PHP “X-Powered-By: PHP/5.x.x-1ubuntuX.X”

  1. sudo vi /etc/php5/apache2/php.ini
    expose_php = Off
  2. sudo service apache2 restart

REFERENCES:

DTD for logback.xml in Eclipse

After fixing the validation error in my Ant build.xml files, I got to wondering about the other common XML files in my projects. I’ve used Logback on many of my recent projects and it’s configuration has similar warnings that can be resolved in the same manner.

The simplest method to silence the warning is to add a DOCTYPE to the logback.xml files, between the XML declaration and the configuration. Official documentation seems to indicate that a DTD is not possible or likely.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE configuration>
<configuration>

NOTE: For what it’s worth, this approach should work for any XML file to remove the error in Eclipse.

REFERENCES:

DTD for Ant build.xml in Eclipse

I’ve seen this validation error in Eclipse for a few releases and finally got tired enough of seeing it that I did some research.

The simplest method to silence the warning is to add a DOCTYPE to the build.xml files, between the XML declaration and the project, there are a few more complicated methods, but this one works well for the cases I’ve experienced.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE project>
<project name="Example"...>

REFERENCES:

Eclipse compiler error when using sun.misc.Base64Encoder reference

I’ve recently been doing some work with code that is still running in a Java5 environment, to make matters worse, no new libraries can be added to the application. With these restrictions, I’ve had to resort to using only functions available in the standard installed JVM. The code relies on HTTP Basic authentication, and thus needs to use Base64 encoding.

The following classes were to be used…

import sun.misc.BASE64Encoder;
import sun.misc.BASE64Decoder;

Unfortunately, Eclipse did not like this and gave an error…

Access restriction: The type BASE64Decoder is not accessible due to restriction on required library C:\jdk1.5.0_22\jre\lib\rt.jar

Thankfully, this class (while not recommended, is in every build of the JVM that I have seen), you can tell Eclipse to only ‘Warning’ on it’s usage…

Window -> Preferences -> Java -> Compiler -> Error/Warnings.
Select Deprecated and Restricted API. Change it to warning.
Change Forbidden and Discouraged Reference and change it to Warning, or as needed.

BTW, I would normally rely on the commons-codec.jar for this functionality, and use org.apache.commons.codec.binary.Base64 for this purpose.

REFERENCES:

NetBeans jdkhome error

After updating the JDK on my development workstations, NetBeans started reporting the following at each start up.

Cannot locate java installation in specified jdkhome:
C:\Program Files\Java\jdk1.7.0_04
Do you want to try to use default version?
[ Yes | No ]

Thankfully, after a little searching, I found that the solution is very simple. You can change the value or comment it out with a # in:
C:\Program Files\NetBeans #.#.#\etc\netbeans.conf

netbeans_jdkhome="C:\Program Files\Java\jdk1.7.0_04

REFERENCES:

Overriding MSIE’s Friendly Error Message screens

IE overrides several HTTP error status pages but it has a size threshold. Only if the error page send by the server has a large enough body then IE decides it’s meaningful and displays it.

Usually to be safe you should make error pages that are larger then 512 bytes. The threshold varies per HTTP status code. You can look at what your thresholds are currently set to. In IE 5 and greater the settings are stored in the registry under [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\ErrorThresholds]

Err Size(bytes):

  • 400 512
  • 403 256
  • 404 512
  • 405 256
  • 406 512
  • 408 512
  • 409 512
  • 410 256
  • 500 512
  • 501 512
  • 505 512

REFERENCES:

Custom 404 Page for Tomcat web applications

This is a relatively common problem in JSP based apps as you need to understand the configuration. It’s further complicated if you use Apache HTTPD in front of the Apache Tomcat server to process requests as you need to know where each request is processed.

For this example, we will use the standard 404 error, but you can also intercept other errors for custom pages.

  1. create 404.jsp:

    <% final SimpleDateFormat simpleDate = new SimpleDateFormat("EE MMM dd yyyy hh:mm:ss aa zzz");
    final String dttm = simpleDate.format(new Date()); %>
    <html>
    <title>404 Not Found</title>
    <ul>
    <li>Time: <%= dttm %></li>
    <li>User-Agent: <%= request.getHeader("User-Agent") %></li>
    <li>Server: <%= request.getServerName() %></li>
    <li>Request: <%= request.getRequestURI() %></li>
    <li>Remote: <%= request.getRemoteAddr() %></li>
    <li>Referer: <%= request.getHeader("Referer") %></li>
    </ul>
    </html>
  2. in WEB-INF/web.xml – add the following (NOTE: location within the file is important but outside the scope of this post)

    <error-page>
    <error-code>404</error-code>
    <location>/404.jsp</location>
    </error-page>
  3. You might want to force the HTTP Header to give something other than a ‘404 status’ code, otherwise MSIE will show an unstyled ‘friendly error message’ if the user has not turned off the default setting. Unfortunately, this also means that search engines might index these pages that should not exist.

REF:

Javascript try/catch/finally

I’ve found that many developers (including myself) that have been coding javascript for some time don’t realize that javascript added the try/catch pattern from Java quite a while ago and that all modern browsers support it.

Here’s the standard pattern, the ‘finally’ of course is optional for when you require it.

try{
// put your code here that may experience a runtime error/exception, i will show division by zero in this example
var x = 1;
alert(x/0);
}
catch(e){
if(e instanceof Error){
alert(‘an error has occurred:name=’ + e.name + ‘|message=’ + e.message);
} else {
alert(‘an unknown exception has occurred’);
}
}
finally{
alert(‘now we are done’);
}

A little more on this… like in Java, there are types of Errors, and you can rely upon ‘instanceof’ to determine them appropriately, here are a few of the common types in JavaScript 1.5:

  • EvalError
  • RangeError
  • ReferenceError
  • SyntaxError
  • TypeError
  • URIError

REFERENCE:
http://www.devarticles.com/c/a/JavaScript/Exception-Handling-in-JavaScript-Using-Multiple-Exception-Handlers/

Cheers

JavaScript code quality

I’ve programmed in a lot of different languages, and with various IDE’s. The one area that has always been lacking is a simple means to review JavaScript code for common errors, both syntactical and format. This is where JSLint and JavaScript Lint come in…. these represent the tooling previously available to other languages like C++ and Java, where you can analyze code without actually executing it to identify problem areas. Often, these are items like ‘missing semicolons’ that occasionally cause difficult to find errors in browsers.

These can be scripted to execute from the command line or within (some) IDE’s on several operating systems.