On 01/03/2011 02:22 PM, Brion Vibber wrote:
Since ApiSVGProxy serves SVG files directly out on the local domain as their regular content type, it potentially has some of the same safety concerns as img_auth.php and local hosting of upload files. If that's a concern preventing rollout, would alternatives such as wrapping the file data & metadata into a JSON structure be acceptable?
hmm... Is img_auth widely used? Can we just disable svg api data access if $wgUploadPath includes imageAuth ... or add a configuration variable that states if img_auth is an active entry point? Why dont we think about the problem diffrently and support serving images through the api instead of maintaining a speperate img_auth entry point?
Is the idea that our asset scrubbing for malicious scripts or embed image html tags to protect against IE's lovely 'auto mime' content type is buggy? I think the majority of mediaWiki installations are serving assets on the same domain as the content. So we would do good to address that security concern as our own. ( afaiak we already address this pretty well) Furthermore we don't want people to have to re-scrub once they do access that svg data on the local domain...
It would be nice to serve up diffrent content types "data" over the api in a number of use cases. For example we could have a more structured thumb.php entry point or serve up video thumbnails at requested times and resolutions. This could also clean up Neil's upload wizard per-user temporary image store by requesting these assets through the api instead of relying on obfuscation of the url. Likewise the add media wizard presently does two requests once it opens the larger version of the image.
Eventually it would be nice to make more services available like svg localisation / variable substitution and rasterization. ( ie give me engine_figure2.svg in Spanish at 600px wide as a png )
It may hurt caching to serve everything over jsonp since we can't set smaxage with callback=randomString urls. If its just for editing its not a big deal, untill some IE svg viewer hack starts getting all svg over jsonp ;) ... Would be best if we could access this data without varying urls.
Alternately, we could look at using HTTP access control headers on upload.wikimedia.org, to allow XMLHTTPRequest in newer browsers to make unauthenticated requests to upload.wikimedia.org and return data directly:
I vote yes! ... This would also untaint video canvas data that I am making more and more use of in the sequencer ... Likewise we could add a crossdomain.xml file so IE flash svg viewers can access the data.
In the meantime I'll probably work around it with an SVG-to-JSONP proxy on toolserver for the gadget, which should get things working while we sort it out.
Sounds reasonable :)
We should be able to "upload" the result via the api on the same domain as the editor so would be very fun to enable this for quick svg edits :)
peace, --michael