On 27/10/2011, at 3:19 PM, Mark Nottingham wrote: >> I floated the idea a while back that we get rid of variants altogether and >> instead use an HTML representation to offer the user a choice of how to view >> the information that includes <pre> elements with JSON and XML formatted >> text. It could also have a nice human readable representation so that users >> could directly navigate around in the browser. Remember that the only use >> case justifying variants are human developers who want to see what the JSON >> or XML will look like. >> If we do this, then we have GET /server/1234 and everything is clean. Jorge >> pointed out one slight problem with this: <pre> can only display textual >> representations. So no pdfs or excel spreadsheets without conneg. If we >> could live with this, getting rid of the variants altogether seems like a >> win. > > > Why not just return HTML that uses XHR to pull in the JSON and XML on-demand, > when the Accept header prefers HTML?
Actually, I take it back -- we probably shouldn't be putting any HTML on the same host:port as the API, at all -- the cost of a successful XSS against the raw API is too high, even if there are ways to mitigate the risk. <http://www.theregister.co.uk/2011/10/27/cloud_security/>: > The researchers said Amazon was also vulnerable to cross-site scripting (XSS) > attacks that could have allowed users logged onto its online store to hijack > an AWS session, using injected JavaScript code. The researchers demonstrated > the vulnerability, only possible because signing into Amazon store > automatically creates a concurrent AWS cloud service session automatically, > at an ACM workshop on cloud security during a presentation entitled All Your > Clouds are Belong to us. -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
