2011/1/4 Michael Dale <mdale(a)wikimedia.org>rg>:
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?
The separate img_auth.php entry point is needed on wikis where reading
is restricted (private wiis), and img_auth.php will check for read
permissions before it outputs the file. The difference between the
proxy I wrote and img_auth.php is that img_auth.php just streams the
file from the filesystem (which, on WMF, will hit NFS every time,
which is bad) whereas ApiSVGProxy uses an HTTP request (which will hit
the image Squids, which is good).
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?
No, IEContentAnalyzer will reject anything that would "confuse"
IE.
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...
MW was written with this same-domain setup in mind, and WMF is one of
the very few setups out there that uses a separate domain for files.
So I'm fairly sure we don't rely on files being on a different or
cookieless domain for security.
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 )
You should talk to Russ Nelson, Ariel Glenn and the other people
currently involved in redesigning WMF's file storage architecture.
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.
Yes, JSONP is bad for caching.
Roan Kattouw (Catrope)