Archive for January, 2011

HTTPS Mixed Content Warning: Mootools 1.2 and SexyLightBox

January 17, 2011

Though my Victorian sensibilities make it awkward for me to publicly discuss something called SexyLightBox, I will endure the embarassment for you, my semi-devoted readership.

In TEST we got a HTTP Mixed Content Warning on one of our pages. This is the well-known pop-up that says:

“This page contains both secure and nonsecure items. Do you want to display the non secure items”


Since this was a Journey Of Pain I undertook last year, I have healed/suppressed the horrible memories somewhat (along with the ones where I have been abducted by aliens) but the email trail from my outbox allows us to sketchily reconstruct the events.

So I was visited by a vicious UAT tester who, for the purposes of this JOP, was dressed as Lord Monster Raving Loony and carrying a wheelbarrow full of freshly slain ferrets. “The page contains contains both secure and nonsecure items.”, it salivated with disarming charm, “Care For A Ferrett ??”.

“Certainly”, I said lighting one up. “Isn’t that simply due to stochastic fluctuation in maximum latewood density, otherwise known as The Divergence Problem and hence not my fault ?”.

LMRL narrowed twenty-seven of its available fourty-six grotesque eyeballs, forcing them into a reptilian version of the Mexican Wave. “UAT FAIL” it hissed, drew heavily on the ferrett, incinerating it to its toenails and prompty vanished in a cloud of sulphur.

Awfully alone, I started a forensic examination of THINGS DOWNLOADED BY OUR PROBLEM PAGE i.e. images and javascript files. I did indeed find a few images accessed by http instead of https and found the problem went away if I did this AND ALSO commented out mootools 1.2 javascript file. Somewhere in the wild, the ZenPhoto support blog to be exact, I found an article which did indeed appear to nail the uncompressed version of Mootools as a source of Mixed Content Warnings.

Since I could not find an uncompressed version of Mootools 1.2, I downloaded v1.2.5 uncompressed, whacked it in and acheived temporary relief, except that now (blush) AttractiveLightBox.js issued js errors. Curses that pernicious little flirt, let me be direct, SexyLightBox has a dependence on Mootools 1.2.

So I investigated further and found that NaughtyLightBox ignored the document protocol for its image download. Here she is in all her wanton shame:

this.strBG = this.options.imagesdir+’/’+this.options.color+’/’+this.options.backgroundIE;
this.strBG = this.options.imagesdir+’/’+this.options.color+’/’+this.options.background;

The Fix

I fixed this by adding a dynamic call for the page protocol to the image path like so:

this.strBG = document.location.protocol + this.options.imagesdir+’/’+this.options.color+’/’+this.options.backgroundIE;
this.strBG = document.location.protocol + this.options.imagesdir+’/’+this.options.color+’/’+this.options.background;

Mootools.js was not the issue, though commenting out caused the mixed-content warning to go away because there is a dependence on Mootools from censoredlightbox.

Moral Of The Story
Beware of javascript files that ignore document protocol for image download.

Now if you’ll excuse me I must go cover some table legs with a very long tablecloth.


String Comparison Fails And String Contains A Dash

January 14, 2011

Our Integration Partner, using a Web Service of ours via their Workflow application, was complaining that our WCF Service was broken in the UAT environment.

The error logs showed this:
2011-01-13 16:23:07,645 [5] ERROR Error in PerformPolicyLookup PolicyNumber: 9999999 Error: Unknown client name “SmithsCrisps – NZ”

But when I accessed the same Web Service through a Visual Studio Project running on my Desktop the Web Service call ran fine.
The URL for that Web Service had changed just a fortnight back so I suggested that maybe they were not accessing the correct Web Service and that they needed to check what URL they were using or maybe regenerate their proxy classes.

Well their Developer got back to me and said that in the Database the dash in “SmithsCrisps – NZ” was stored as an Elongated Dash, properly known as the em Dash, Unicode 2014, whereas the Web Service tested for Client Name based on the en dash, Unicode 2013.

…which doesn’t really add up since the actual Client Name parameter must have been passed as an Elongated Dash (em dash) if it ended up actually matching records on the database, but yet it supposedly also matched against en dash in the parameter validation part of the Web Service call.

So he reckons he updated the Database to use en dashes (the short ones).

…sounds a bit fishy.

But anyway, for our purposes, if you find a String Comparison is failing and the String in question has a Dash in it then be aware that there are several different kinds of dashes.Everthing you ever wanted to know about Dashes is here courtesy of the ubiquitous Wkipedia.

Naturally, dashes can be things that matter most

And one more thing: make sure there are no hyphens in the mix as well or else you may find yourself requiring medical assistance.