A cautionary tale for users of Kaspersky's URL Advisor plugin

[fleetfootmike]

The non-techie summary - disable the Kaspersky URL Advisor browser plugin, unless you want some website forms to break.

So... my friend Tony is tearing his hair out (what little he has left) because his new iMac won't submit web forms in Firefox - he's pretty much at the point of giving the thing away. After suggesting all the obvious things over the phone (make sure JS is turned on, etc), I get him to bring it round, and have a peek.

It transpires that (for example) if he submits a certain form on parcel2go.com, none of the form fields get submitted. So, we run the same query on the wife's MacBook Air. 

Works fine.

Ok. Time to dig out the Web Developer tools and have a look - it seems that they have a form validation Ajax request that on Tony's Firefox returns a 500, on Anne's a 200. A closer look reveals one rather bizarre difference: on Anne's machine, the request is submitted as a POST with Content-Type: application/json. On Tony's, it's submitted as application/x-www-form-urlencoded... but still has a payload which is clearly JSON.

What.. the...????

*More* digging into the page source reveals that it's done using jQuery's $.ajax(), which defaults to application/x-www-form-urlencoded, and isn't being passed a contentType param.

However, *Tony's* machine has Kaspersky's URL Advisor plugin installed, which comes with its OWN version of jQuery, which seems to be loading in a manner that overrides the one Parcel2Go want to use (which latter evidently sets a default contentType of application/json in $.ajaxSetup(). 

Disable Kaspersky URL Advisor, and all is shiny again.

Comments

[alitalf.livejournal.com]

Scarily, that almost makes sense. Not that I could have figured it out myself from a standing start.

Back in the dark ages there was html, which is simple. CSS added some complexity, but gave a lot more control. Javascript, written as code that does something - again, a bit of complexity for a lot of useful stuff.

That was all too easy, so they had to invent object oriented javascript, where it is not clear what statement actually *does* anything, and Ajax. It just has to be pushed to the point where it is difficult to understand, and so complex that it is easy to break. If it doesn't fail relatively easily, it doesn't have enough features. <sigh>

[fleetfootmike.livejournal.com]

I'm actually remarkably pleased with myself for figuring it out. Tony was literally on the verge of giving the Mac away, which ... well, I'd have taken it, but it wasn't the point :D

[occams_pyramid]

jQuery is supposed to make everything much simpler, which is why it's used so much. Messing up jQuery is going to break a *lot* of sites.

Time to dig out the Web Developer tools

[armb.livejournal.com]

What tools do you recommend for that sort of thing? I've used Firebug a bit, and I know of Fiddler but haven't tried it.
Wireshark I tried very briefly before discovering I was asking the wrong question (Wrong: "Why does this Android phone not get an IP address from the router when the Windows desktop and Linux laptop worked fine with it a moment ago"; Right: "Why is this router not working when it did a moment ago". (Answer "no idea, BT have raised a support ticket, but it seems to have got better again".))

Re: Time to dig out the Web Developer tools

[fleetfootmike.livejournal.com]

For this, just the Web Developer tools on the Tools menu was enough to see the request/response details.

In general, though, I use Firebug on Firefox, or the Safari Web Inspector.

[filkerdave.livejournal.com]

I have no idea how one would figure that out, but it's pretty cool to find out all the steps.