[RESOLVED] NoScript prevents XML?

[FoamHead]

With NoScript freshly installed, I hit http://www.worldofwarcraft.com/ which is pure XML. The index.xml uses XSL file /new-hp/layout/layout.xsl which, inside some templates, uses several scripts. The odd thing is the only output I get is the raw (outside of tags) text present in the index.xml template. None of the contents of /new-hp/layout/layout.xsl got rendered. I expected to see the full page with all scripts disabled just like any HTML page, but NoScript either blocked processing of /new-hp/layout/layout.xsl or inhibited the instantiation of the templates.

With scripts enabled on http://www.worldofwarcraft.com/ the page looks and operates correctly, but I'm confused as to why NoScript would inhibit XML/XSL rendering instead of just the <script>'s. Is this normal and correct NoScript behavior? If it is, perhaps it should be added to the FAQ or as a forum sticky because I found nothing on it when searching both.

Thanks all,
-Foam

[GµårÐïåñ]

When a page is using an entirely script based interface creation, using XML in this case for the data, it will be blocked by NoScript, because its a script blocker unless its whitelisted. Its actually doing what its supposed to do. Now there is an additional setting in NS Options|Advanced|Untrusted|uncheck "Forbid XSLT" and it will work just fine. But you risk having some site try and exploit you with XSLT, so use caution. With that disabled, you will see it just fine. Good luck.

[therube]

Not sure that I'm understanding what the problem is?
(I know nothing of WoW.)
But to me, the page looks fine & appears to function properly.
(Not sure what I'm supposed to see as to what is wrong?)

http://www.worldofwarcraft.com/new-hp/layout/layout.xsl

Now on this page, http://www.worldofwarcraft.com/info/, there is a (horizontal) menu block which does not display its' menu items, but that is generated with JavaScript ...

[dhouwn]

Related topic: http://forums.informaction.com/viewtopi ... t=193#p850

[GµårÐïåñ]

Again I repeat, if you have Forbid XSLT checked it will break, if not then it will show fine. Simple as that because the site is poorly coded.

[therube]

Thanks dhouwn. Once again I had to spoof my UA (from SeaMonkey/1.1.16 to Firefox/2.0) in order to see it not work. (Or you all could spoof your UA to SeaMonkey/1.1.16 & you would see that the page does render properly - even with XSLT checked. UA sniffing .)

[dhouwn]

Simple as that because the site is poorly coded.

I would rather say, it's strangely coded, they surely had to cope with a lot of difficulties (like e. g. with https://bugzilla.mozilla.org/show_bug.cgi?id=230214).

I wonder what their reasons were for creating these web sites (worldofwarcraft.com, blizzard.com, battle.net) in such an unusual way… (http://xkcd.com/554/ related?)

[Giorgio Maone]

(http://xkcd.com/554/ related?)

[FoamHead]

When a page is using an entirely script based interface creation, using XML in this case for the data, it will be blocked by NoScript, because its a script blocker unless its whitelisted. Its actually doing what its supposed to do. Now there is an additional setting in NS Options|Advanced|Untrusted|uncheck "Forbid XSLT" and it will work just fine. But you risk having some site try and exploit you with XSLT, so use caution. With that disabled, you will see it just fine. Good luck.

Yup, this is exactly what's happening for me. The data for this is in a few separate places, so here's the summary I've gleaned:

1) Several of Blizzard's big web sites (http://battle.net, http://worldofwarcraft.com, perhaps more...) are written in XSLT (eXtensible Stylesheet Language Transformations -- basically XML templates). In an attempt to offload their servers yet still reach as many people as possible, Blizzard serves client-side XSLT if it thinks your browser can handle it; otherwise it processes the XSLT on the server and sends your client the rendered XHTML.

2) Because XSLT is may be more susceptible to exploitation (see Giorgio's response about it), NoScript blocks XSLT by default. You can alter this behavior via the Forbid XSLT setting in the NoScript Options | Advanced | Untrusted pane.

3) Because of what appears to be poor browser detection (battle.net reference), some modern browsers that support XML are instead getting the server rendered XHTML which makes the site appear as if there are no issues even with Forbid XSLT enabled.

This all makes sense and seems like the prudent course of action for NoScript, but this information shouldn't have been buried. Thankfully the NoScript community rocks , but IMHO this information should have been clearly explained in the FAQ. Given the massive popularity of Blizzard games, I think it warrants clearly explaining the issue so you don't turn off those folks to NoScript.

Thanks for the help, everyone.
-Foam

[Giorgio Maone]

Are they looking for "Firefox" in the user agent string to tell if a browser supports client-side XSLT?
It would seems so, since therube and other Seamonkey users didn't experience any issue.
So a possible work-around would be sending a fake UA string to sites not in your whitelist, but this probably would have other unwanted side effects.
However, as far as I can see, there's at least one bug here to be fixed to improve user's experience with XSLT blocking, and it's that if the blocked stylesheet is from a 3rd party site which doesn't deliver any script, it's not shown in the NoScript permissions menu.
I'll fix that in next release.

[therube]

PS: There is a domain based spoofer, though not sure if it works in FF?
(Only guessing, possibly FF2, but very likely not in FF3?)

Partial Spoofer: a good solution to sniffing?

Download: http://users.skynet.be/fa258499/extensi ... poofer.xpi

[Foam Head]

It looks like Giorgio fixed the bug he mentioned above in the 1.9.2.3 release, however, now Forbid XSLT is being ignored! I'm using NoScript 1.9.2.6 in FireFox 3.0.10 with NoScript Options | Advanced | Untrusted | Forbid XSLT enabled while http://worldofwarcraft.com is NOT in my Whitelist. Using Firefox's View Page Source, I confirmed that I am receiving XML with XSLT which means Firefox is processing and rendering it. All scripts and objects in the rendered XHTML do seem to be blocked, but the Forbid XSLT setting is obviously not functioning.

-Foam

PS. Yes, I finally registered an account .

[therube]

Wonder if WOW didn't make a change to their website?

No, that's not it.
Looks like some change in NoScript is either causing the site to render as expected - even with XSLT blocking enabled, or XSLT blocking is now broken.

Another site for reference: http://www.hirsch.sth.ac.at/~robert/the ... -index.xml.

PS: Note if you happen to be running FF3.6, its UA is Minefield/3.6a1pre & that will render WOW correctly (again like SeaMonkey does).

1.9.2.3 says:

Code: Select all

x Fixed external XSLT sources not being reported in NoScript menus
  even if blocked unless a different type of active content comes
  from the same origin

so maybe some breakage from that.

[GµårÐïåñ]

Foam Head, I think it goes back to the browser detection/sniffing scheme discussed earlier. Its not so much that it is being ignored but rather since not offered during the sniffing as a capable option for the browser, the site is ignoring it and pushing server side compiled version. That would be my guess but I could be wrong and only Giorgio can verify if there is actually a flaw introduced on that one.

[dhouwn]

That would be my guess but I could be wrong and only Giorgio can verify if there is actually a flaw introduced on that one.

Just look in the page source and you'll see whether the XSL transformation has already taken place on the server side.

BTW:
enforcing (X)HTML: http://www.blizzard.com/store/?rhtml=y (sent as "application/xhtml+xml" for some browsers)
enforcing XML: http://www.blizzard.com/store/?rhtml=n (works in IE, fails in Opera)