2011/1/4 Michael Dale <md...@wikimedia.org>: > 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) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
