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:
https://developer.mozilla.org/En/HTTP_Access_Control
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