# SOAP XML Transform – NWS Forecast

The National Digital Forecast Database is a SOAP web service distributing U.S. forecast data via XML. I recently examined the output with an eye toward incorporating a basic forecast component into a webpage, but found it rather difficult to use directly. The purpose of this post is to share the process I used to transform the XML into an easier to use format.

An example of the format returned by my transformation is reproduced below.  To see an example of the original XML format returned by the service use the tool at http://graphical.weather.gov/xml/SOAP_server/ndfdSOAPByDay.htm.

The PHP code retrieving the original XML and returning the transformed version is reproduced below. A few notes are in order. First, you may note that E_NOTICE is suppressed. This is because it is possible that some elements may be empty and not return any data. Second, the xpath() method of the SimpleXML object returns an array of SimpleXML objects, of which we will generally want the 0th element. As a matter of convenience it is being retrieved via the list($someVar) construct. Finally, there is a lot of implicit casting going on as the xpath() method is cast to a string containing the element’s text. At a high level, the code begins by matching the time-layout key from the <weather> element to the time-layout key of the corresponding <time-layout> element. The key itself is parsed by the sscanf() function in line 18 to retrieve the number of elements to be processed. Both elements are then iterated in lock-step by the for loop, generating the transformed XML. Note that the same time-layout key matches the <conditions-icon> element and is also processed therein. The <temperature> elements are processed in a similar manner, with the added feature of being mapped to the appropriate period in the new XML. Note that the maximum and minimum types processed separately as they both have independent <time-layout> elements. Hopefully, this code will be useful to others in transforming this rather unfriendly XML into a format more amenable to simple applications. # PHP VIN Code Validation Since 1981 Vehicle Identification Numbers in North America have followed a standard which provides a check digit to aid in the identification of transcription errors. Reproduced below is my PHP implementation that calculates a checksum and compares it to the check digit. The code begins by converting the string to uppercase and checking that the passed value matches a regex looking for exactly 13 uppercase alphanumeric characters, excluding the letters I, O and Q, followed by exactly 4 digits. On success the code proceeds to implement the weighted checksum algorithm using the private helper function getNumVal($char) as a lookup table. Note that the 9th character is the checksum, and thus excluded from the calculation.

Once the total is calculated it is divided by 11 and its remainder becomes the checksum, with ‘X’ representing 10. It should be obvious that the mod 11 operation provides limited protection against errors since there is a 1 in 11 chance an invalid VIN code will pass the test. Nevertheless, the algorithm has saved countless invalid VIN codes from making into my databases.

As shown below, it is important to do some cursory error checking in the web form before passing the input to this method. This greatly assists the user in determining the most likely causes of error.

# PHP Passwords with Character Arrays

Here’s a simple function I recently wrote to randomly generate passwords in PHP.

Simplified a bit, this is equivalent to:

This works because like C, PHP allows a string to be accessed as an array of characters using either brackets or braces:

For 8-character passwords the algorithm above will produce a string containing at least two of the four character types (upper case, lower case , digits and symbols) more than 99.9% of the time. This can be shown by removing from the set of all possible passwords those passwords that contain only one of the four character types.

All possible passwords: (26+26+10+19)8 = 818
Passwords containing only lower case characters: 268
Passwords containing only upper case characters: 268

$P=\frac{81^8-(26^8+26^8+10^8+19^8)}{81^8} = 1-\frac{26^8+26^8+10^8+19^8}{81^8} = .999765\ldots$

This comports with the results of a run of 10,000,000 samples which yielded 9,997,635 passwords containing characters from at least two groups.

Note that this article is meant as a demonstration of one way to quickly generate general purpose passwords. If you need to generate highly secure passwords you will need to do more homework, including but not limited to replacing the mt_rand function with a cryptographically secure PRNG.

# jQuery Lightbox

Creating a centered lightbox that dynamically resizes the image and maintains centering within the browser window is simple if you know the technique.  Hopefully this short article will save someone else the time I spent finding a solution.  I have tested the technique in the current (as of posting date) versions of IE, Firefox and Chrome. Note, however, that the JSFiddle example below does not work in IE.

While I have used jQuery in this example, CSS3 is the real hero and the technique itself is framework agnostic.  It should be noted however, that IE8 does not support the required CSS property.

As you will note in the code below, the technique uses an empty <div> that will overlay the viewport and display the desired image as its background.  This method allows us to use the CSS3 background-size property with the contain value that will scale the image with the window while maintaining aspect ratio.  Centering is provided by the background-position property as shown in the code above.

I have used jQuery to dynamically assign the value of the background-image property based on the href in the anchor tag.  This allows clients without JavaScript enabled to access the image as an ordinary link.  Of course, jQuery also provides the cool fading effect.  Most users will probably want to extend the functionality of this rudimentary lightbox using their framework of choice or even straight JavaScript.

# eToken WSO and IE10

For the last several years I’ve been using the SafeNet (formerly Aladdin) eToken Web Sign On (WSO) product to manage my credentials for more than two-dozen websites. Unfortunately, after upgrading to IE10 the browser extension no longer works.

While version 5.2 of the WSO software only officially supported Internet Explorer up to version 8, I experienced no issues running it on IE9. However, the browser extension no longer functions properly under IE10. Undaunted, I simply renewed my license in order to download the updated version of the WSO software. Sadly, I found that the software had not been updated in several years.

Upon contacting SafeNet I was advised that “The latest WSO version is 5.2 and it is end of development for now.” While they did direct me to an alternative product offered by Evidian, it appears to be an enterprise-level offering with no viable support for one-off consumer application.

eToken was a great consumer-friendly product for securely managing PKI and web credentials in a convenient USB smartcard. If SafeNet truly intends to abandon the WSO product it would great if they would release the code to the open source community so it could be extended to support modern browsers. Unfortunately, this seems unlikely since it would ostensibly mean openly releasing the API which is part of the SDK that it licenses for profit.

For now I will continue to use eToken for PKI and am trying out KeePass for “Web Sign On.” What’s your solution?

# Rounding Sales Tax Calculations

Until recently, Minnesota rounded sales tax calculations by looking out to the ten-thousandths place – as reflected in the state’s official sales tax charts.  Earlier this week I discovered that the state now has an online sales tax calculator that rounds by looking out only to the thousandths place.  This means that the 6.875% sales tax on $1.38 could be either$.09 or \$.10 depending on which “official” resource is consulted.

As a programmer seeking to write code that produces accurate and consistent results this ambiguity spurred me to do a bit of research – some of which may help you to resolve similar questions.

It turns out that Minnesota – and more than twenty other states – are members of an organization known as the Streamlined Sales Tax Governing Board that seeks to establish uniform standards across member states.  The organization’s uniform rounding rule may be what compelled Minnesota to make the change.

The rule specifies that calculations be carried out to the thousandths place.  Any fraction of a cent less than one-half is to be rounded down and any fraction of a cent greater than or equal to one-half is to be rounded up to the next full cent.  The official rule is defined in §324 of the Streamlined Sales and Use Tax Agreement.  You can learn more about the SSTGB and find out if your state is a member by visiting their website.