Kevin Ragsdale: Visual FoxPro 9.0

I’ve Seen This Before. It’s An Outlier.

UPDATE: Finally figured out this issue. I was encrypting an XML file, which caused some illegal characters to appear from time to time (the “outlier” instances). Took out the header of the XML file, and everything works as expected.

I recently added some functionality to an app which allows the app to login to a web service with a username and password. Since I want to retain the login information (so the user doesn’t have to be prompted to enter their credentials every time), I store the username and password in an XML “settings” file.

I’ve been using Craig Boyd’s excellent VFPEncryption FLL to encrypt/decrypt the password. The user enters her username and password, the password is encrypted, and the username and password are written to the XML file. It’s been working great on thousands of computers.

Except for four computers.

When the app needs to retrieve the username and password, it opens the XML file, decrypts the password, and tries to login to the web service. But on these four computers, the decryption crashes with “API call caused an exception”.

Working with a customer on this particular problem, I pointed him to the XML file and asked him if he would be willing to change his password for the web service – just to see if maybe we could get past the crash.

He changed a couple of characters in his password, and voila! – it worked with no problem.

So he went back to his original password and made note of the encrypted password which was stored in the XML file. Oddly, the encrypted password contained an embedded carriage return:

<PASSWORD>?-arP?­Z?=¤¨?? ;?¥
?8??*ù©y</PASSWORD>

He changed a couple of characters, and made note of the encrypted password again:

<PASSWORD>ðF’1L’|„ žU­MU¨èˆfâ‚?TÀn Çvõ’U</PASSWORD>

Freaky, huh? When I run the code from the app via the Visual FoxPro Command Window, including the STRTOFILE() and FILETOSTR() lines to write and read the XML file, it works with no problem.

The customer, a former software developer, tried 16 more random passwords – just to see what would happen. Every one of them worked flawlessly.

So, after successfully trying 17 passwords he went back to the original. Same problem: an embedded carriage return in the stored encrypted password, and an API exception when decrypting it.

The last thing he said to me was:

Then it hit me, not the first time I’ve seen this. It’s an outlier. There is a very good reason why this is happening. You may close the ticket now. The function is working fine.