Elephant paints self-portrait

Wow this elephant is terrible. He draws the feet directly on top of the ground rather than inset. Doesn't he know anything about linear perspective???? :)

giant starfish found

From
http://www.cnn.com/2008/TECH/science/03/21/antarctic.search.ap/index.html

Looks like a giant species of star fish has been found. These guys would look better with faces. I propose that we tattoo faces on all star fish:

war haiku

two soldiers each see
a cruel and mindless killer.
young face peers through door.

Robust DHTML

DHTML is the technique of combining JavaScript and CSS to create dynamic page elements that are not possible with static HTML. For example, it's easy to dynamically show or hide page elements, or move them.

Given the differences in broswers, it is by nature a bit difficult to write clean DHTML. And worse, most free DHTML examples of code on the internet are written poorly, as they have countless little browser checks, and conditional code branches like:

    if(isIE){
        //do something one way
    } else if(isNetscape6){
        //do something else another way
    } else if(isNetscape4){
        //do something else yet another way
        //...
    }

This is poor design, as it is brittle, hard to maintain, and often breaks when new browsers are released or change. And likely, any browser not in the checks will not supprted correctly either. Also I see a lot of newer DHTML scripts doing more css and in place of javascript, although, I still think css support across browsers is still a bit flakey.

A better way is to design something with these simple principles:

1. sniff for functionality rather than browser name/version
2. create a single wrapper function that encapsulates brower specific code
3. page should "degrade gracefully" if possible (meaning the page will still be readable and functional if javascript or dhtml not supported)

Here is a small example designed with these principles in mind (modified from Apple Developer's site):

    // cross-browser dhtml utilities
    // wrap blocks of html in div> tags with unique id's

    // try to get a style object given its id
    function getStyleObject( objectId ) {
        if ( document.getElementById && 
                document.getElementById( objectId ) ) {
            // W3C DOM
            return document.getElementById( objectId ).style;

        } else if ( document.all && document.all( objectId ) ) {
            // MSIE 4 DOM
            return document.all( objectId ).style;

        } else if ( document.layers && 
               document.layers[ objectId ] ) {
            // NN 4 DOM.. note: this won't find nested layers
            return document.layers[ objectId ];

        } else {
            return false;
        }
    }

    // a template function for setting two-state style properties
    function setStyleBoolean( objectId, booleanValue, 
          propertyName, valueOn, valueOff ) {
        var styleObject = getStyleObject( objectId );

        if ( styleObject ) {
            if ( booleanValue ) {
                styleObject[ propertyName ] = valueOn;

            } else {
                styleObject[ propertyName ] = valueOff;
            }

            return true;

        } else {
            return false;
        }
    }

    // try to show/hide object.  a empty visual space will remain in place
    function setObjectVisibility( objectId, booleanValue ) {
        return setStyleBoolean( objectId, booleanValue, 
            'visibility', 'visible', 'hidden' );
    }

    // try to insert/remove object from display.  page will redraw and no space will remain in place
    function setObjectDisplay( objectId, booleanValue ) {
        return setStyleBoolean( objectId, booleanValue, 
           'display', '', 'none' );
    }

    // try to move object
    function moveObject( objectId, newXCoordinate, newYCoordinate ) {
        var styleObject = getStyleObject( objectId );

        if ( styleObject ) {
            styleObject.left = newXCoordinate;
            styleObject.top = newYCoordinate;
            return true;

        } else {
            return false;
        }
    }

This code works in all javascript-enabled browsers I've tested (FireFox 1+, IE 4+, Netscape 4+, Opera), despite having no checks for any specific browser. Also, all code that interfaces directly with the broswer api is isolated, so it is very easy to extend or debug if there ever is a problem.

To use the code above, for example, save it to a file named "dhtmlutil.js" and use it like:

    <html>
    <head> 
        <script language="javascript" 
               src="dhtmlutil.js"></script>
    </head> 
    <body> 
     
    <h2>Clean DHTML example</h2>
     
    <div id="test1"> 
        this is a block of html that can be hidden or removed
    </div>
     
    <p>
        you can change the properties of the 
        block above with these buttons:

    <p> set display
    <input type=button 
        onclick="setObjectDisplay('test1', false);" 
        value = "off">
    <input type=button 
        onclick="setObjectDisplay('test1', true);" 
        value = "on">

    <p> set visibility

    <input type=button 
        onclick="setObjectVisibility('test1', false);" 
        value = "off">
    <input type=button 
        onclick="setObjectVisibility('test1', true);" 
        value = "on">

    </body>
    </html>

If you add more functions, put them all together in the head with the included file.

to use hyperlinks, use a dead link with an onclick handler like:

    <A HREF="javascript:void(0)" onClick="....">

DEGRADING GRACEFULLY

A fundamental problem with DHTML is figuring out how to design the page so that it degrades gracefully. In other words, if javascript or css aren't supported, the user can still use the page. This is especially difficult for menus, and othter page entitties that are hidden/collapsed by default. A menu is the most important element on the screen, and should be viewable on the lowest common denominator. Even if old browsers are obsolete, there is always a chance it won't be compatible with future broswer releases/bugs (for example, the Netscape 6 to 7 fiasco). The general rule is:

4. Any hidden entity should be visible if DHTML is broken.
5. No core functionality should ever depend on DHTML.

The best way to achieve this is to wrap javascript around css elements in the header, such as:

    //write styles via javascript, to degrade gracefully
    var idx = 'yourid';
    if (document.getElementById || 
           document.all || document.layers ){
        document.write('<style type="text/css">')
        document.write('.switchcontent{display:none;}')
        document.write('<\/style>')
        document.write('<style type="text/css">')
        document.write('#' + idx + '{display:block;}')
        document.write('<\/style>')
    }

This code, for instance, will hide all members of the class "switchcontent," except for the one with the id "sc1". So, if javascript or css is broken, all these entities will be visible. Note that these tags conflict, but that the style closest to the element takes precedence. Corresponding div tags for this code might look like:

    <div id="sc1" class="switchcontent">
        something visible by default
    </div>
    <div id="sc2" class="switchcontent">
        something invisible 
    </div>
    <div id="sc3" class="switchcontent">
        something invisible 
    </div>

Calling command line tools from a web application

Occasionally, it's convenient (or practically necessary) to have a web application call a command line tool. If not done wisely, it can open up a huge security risk. For example, suppose we are using a simple command line tool that excutes a command like:

./simpletool $username

Now suppose someone creates a new user named "bill;rm -rf /" and passes it to a command line utility which executes:

./simpletool bill; rm -rf /

This will of course wipe everything out under /. Not good! It's not hard, if these interfaces have not been thought through, to find a string that does anything we want. Quotes, single quotes, and other special chars are easy to slip through and create major security holes. Buffer overflows could also be a problem... the command line can only accept a string of some finite length.

But while it's not ideal, it's not a huge security risk as long as there's some special safety considerations when handling user input. Here's a short list of security principles when using system calls:

After authentication and authorization is handled:

1. for all data, limit strings to a known set of characters
2. limit all strings to known sizes
3. limit all hashes of user input to known fields
4. avoid passing any data to the command line which isn't
programatically generated by you. If possible write user data to file, and pass your file names around. Otherwise, escape the data properly ... especially non-alpha-numeric chars like " ' ; \ ` $() which have meaning on the command line! Or better yet, just don't pass it on the command line.
5. escape all data that has special meaning (or could have special meaning) in the context in which it is used. For example, in a tab-delimited file, tab chars have special meaning.
6. limit file permissions to bare minimum ... nothing can be executable.
7. keep log of all interactions (leave the created files around for reference)

Using an SSL certificate for IIS under JBoss/Tomcat

If your certificate was requested for IIS, it will likely throw a pop up warning on pages if you install it under JBoss. Although there is a way to fix this.

For different servers, often the CA will use a different chain to sign your SSL cert. The only trick is to explicitly chain these together when building a keystore. This takes a little guesswork, but there are a limited number of intermediate and root certs.

To test out a configuration, it's probably best to add an entry in the local hosts file on the machine, and use a local (or development) server that can be started and stopped quickly.

For example, if it's a go daddy certificate, google for "go daddy root ca". You might get this page:

https://certificates.godaddy.com/Repository.go

Download them all for testing.

in my case, these worked:
intermediate: gd_intermediate.crt
root: gd-class2-root.cer

But overall, use the same instructions below as below:

Setting up SSL in JBoss/Tomcat with an Intermediate SSL CA

Verisign has switched to using a "intermediate" certificate authority (CA). These are a little tricker to install. The trick is getting the appropriate intermediate and root CA files from verisign, and "chaining" together into one file. Basically just concatenating them... one after the other with a header.

-----
General explanation ... Assuming you have these files:

* server.key - your certificate's private key
* server.crt - your certificate
* inter.crt - the intermediate CA that signed your certificate
* root.crt - the root CA that signed the intermediate CA

First, concatenate the CA certs. Be sure the intermediate CA goes first:

$ cat inter.crt root.crt > chain.crt

Next, export the pkcs12 file:

$ openssl pkcs12 -export -chain -inkey server.key -in server.crt\
-name "server" -CAfile chain.crt -out server.p12

You'll be prompted for a password ... this the the one referenced by the server.xml config .
Enter something ... don't leave it empty.

Now, you can use keytool to verify:

$ keytool -list -v -storetype pkcs12 -keystore server.p12

Requires the password entered above... Then you should see a line like:

....
Certificate chain length: 3
....

That's it. Since this is complex, Here's a simple script that should work, with minimal editing:

#!/bin/sh

# this script creates keystores for domains

# notes on script setup

# server_key - The file name of the private key for server.

# server_crt - The file name of the certificate for server.

# cert_name - Something unique, can be anything, just
# a friendly name.

# inter_crt - The file name of the intermediate
# certificate authority (CA)
# The intermediate CA can be downloaded from Verisign.
# although it might take a bit of googling to figure out where
# it is. Try searching for "Verisign intermediate certificate"
# for example.

# root_crt - The file name of the root certificate (from verisign)
# which signed the intermediate CA
# This either needs to be .cer or b64 format.
# The only difference is a header footer
# which may need to be added (see below echo's).
# The package of roots can be downloaded from verisign.
# Good luck guessing which one it is! :)
# Usually the error message ...
# or the certificate information in the browser will give a clue.
# Again, google for this. Try searching for (for example):
# "Verisign root certificate"

# chain_crt - The file name where intermediate and root
# is concatenated. Can be anything really.
# Well almost anything ...
# just don't overwrite some important system file :)

# out_file - The file name where the keystore file is saved


#set up your file paths and variables ...

server_key=yoursite.net.key
server_crt=yoursite.net.cert.2007
cert_name=yoursite_net
inter_crt=verisign_int_ca.cert
root_crt=../roots/VeriSign_Roots/Pca3ss_v4.b64
chain_crt=chain.crt
out_file=keystore_yoursite_2007.pkcs12


echo "creating $out_file ..."
echo "remember"
echo "1. Change owner and permissions"
echo "2. move to jboss/server/default/conf"
echo "3. update jboss/server/default/deploy/jbossweb-tomcat55.sar/server.xml"
echo "4. restart jboss"

echo ""
echo "on errors check $chain_crt ... certs should appear one after the other with header and footer."
echo "the second most likely problem is just having the wrong intermediate and root certs"


## clean up
# rm $out_file
# rm $chain_crt

# build chain certificate

cat $inter_crt > $chain_crt

# may need headers if simply b64
echo "-----BEGIN CERTIFICATE-----" >> $chain_crt

# might need extra line feed ... check $chain_crt
# echo "" >> $chain_crt

cat $root_crt >> $chain_crt

# may need footer if simply b64
echo "-----END CERTIFICATE-----" >> $chain_crt

# create keystore

openssl pkcs12 -export -chain \
-inkey $server_key \
-in $server_crt \
-name $cert_name \
-CAfile $chain_crt \
-caname root \
-out $out_file