Comments on: Cross-Domain Data with Rack and Rails http://www.engineyard.com/blog/2009/cross-domain-data-with-rack-and-rails/ Wed, 08 Feb 2012 12:12:12 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Stulseple http://www.engineyard.com/blog/2009/cross-domain-data-with-rack-and-rails/comment-page-1/#comment-4661 Stulseple Thu, 02 Jul 2009 17:55:08 +0000 http://www.engineyard.com/blog/?p=1111#comment-4661 Your blog is so interesting! I have subscribed on rss and I will read it regullary/ Your blog is so interesting! I have subscribed on rss and I will read it regullary/

]]> By: Jon Crosby http://www.engineyard.com/blog/2009/cross-domain-data-with-rack-and-rails/comment-page-1/#comment-1377 Jon Crosby Tue, 09 Jun 2009 18:34:47 +0000 http://www.engineyard.com/blog/?p=1111#comment-1377 Neil, one example might be displaying a widget on your blog that contains your latest 5 status updates on Twitter. Another might be a public transit site that embeds arrival and departure times for various services (trains, buses, etc.). These are cases where read-only data hosted on other sites (sites that use CSSHttpRequest) might be valuable. Neil, one example might be displaying a widget on your blog that contains your latest 5 status updates on Twitter. Another might be a public transit site that embeds arrival and departure times for various services (trains, buses, etc.). These are cases where read-only data hosted on other sites (sites that use CSSHttpRequest) might be valuable.

]]> By: NeilCauldwell http://www.engineyard.com/blog/2009/cross-domain-data-with-rack-and-rails/comment-page-1/#comment-389 NeilCauldwell Wed, 03 Jun 2009 07:56:59 +0000 http://www.engineyard.com/blog/?p=1111#comment-389 Right, thanks Jon. I'm still a little fuzzy on this - your point about the 'second use case' (getting a message) has thrown me as I thought that your example was getting 'Hello Rails' - but this question could clear things up; what would you see as a good use case for CSSHttpRequest from UI perspective? Right, thanks Jon. I'm still a little fuzzy on this – your point about the 'second use case' (getting a message) has thrown me as I thought that your example was getting 'Hello Rails' – but this question could clear things up; what would you see as a good use case for CSSHttpRequest from UI perspective?

]]> By: Jon Crosby http://www.engineyard.com/blog/2009/cross-domain-data-with-rack-and-rails/comment-page-1/#comment-382 Jon Crosby Tue, 02 Jun 2009 18:35:59 +0000 http://www.engineyard.com/blog/?p=1111#comment-382 Neil, CSSHttpRequest does not cover those use cases. It provides read-only data so posting would need to happen independently. For the second use case (getting a message), it requires a new HTTP request. Neil, CSSHttpRequest does not cover those use cases. It provides read-only data so posting would need to happen independently. For the second use case (getting a message), it requires a new HTTP request.

]]> By: NeilCauldwell http://www.engineyard.com/blog/2009/cross-domain-data-with-rack-and-rails/comment-page-1/#comment-353 NeilCauldwell Sun, 31 May 2009 07:05:37 +0000 http://www.engineyard.com/blog/?p=1111#comment-353 Does this enable a client to paste a widget in to their views (an email collection form, perhaps), to post data to the widget provider (i.e. emails post to another domain), and for widget provider to return a message to be rendered in the DOM via CSS, without another http request or redirect? Does this enable a client to paste a widget in to their views (an email collection form, perhaps), to post data to the widget provider (i.e. emails post to another domain), and for widget provider to return a message to be rendered in the DOM via CSS, without another http request or redirect?

]]> By: Randy Reddig http://www.engineyard.com/blog/2009/cross-domain-data-with-rack-and-rails/comment-page-1/#comment-345 Randy Reddig Fri, 29 May 2009 15:47:12 +0000 http://www.engineyard.com/blog/?p=1111#comment-345 Hi, I created CSSHttpRequest. It implements a guard against expression evaluation in IE by specifically making the stylesheet target media=print. I suppose it’s possible, however unlikely, to construct a scenario where untrusted code might be evaluated. It would require the user to print a page at the instant a CHR transport iframe containing malicious CSS is present on the page. Hi, I created CSSHttpRequest. It implements a guard against expression evaluation in IE by specifically making the stylesheet target media=print.

I suppose it’s possible, however unlikely, to construct a scenario where untrusted code might be evaluated. It would require the user to print a page at the instant a CHR transport iframe containing malicious CSS is present on the page.

]]> By: Double Shot #463 « A Fresh Cup http://www.engineyard.com/blog/2009/cross-domain-data-with-rack-and-rails/comment-page-1/#comment-340 Double Shot #463 « A Fresh Cup Fri, 29 May 2009 10:49:01 +0000 http://www.engineyard.com/blog/?p=1111#comment-340 [...] Cross-Domain Data with Rack and Rails – Encoding data into CSS rules to get around cross-domain security policies is certainly one of the nastier perversions of web standards I’ve seen lately. [...] [...] Cross-Domain Data with Rack and Rails – Encoding data into CSS rules to get around cross-domain security policies is certainly one of the nastier perversions of web standards I’ve seen lately. [...]

]]> By: Jon Crosby http://www.engineyard.com/blog/2009/cross-domain-data-with-rack-and-rails/comment-page-1/#comment-338 Jon Crosby Fri, 29 May 2009 05:02:15 +0000 http://www.engineyard.com/blog/?p=1111#comment-338 ActsAsFlinn, the difference between JSON-P and AJACSS is that the later is just read-only data. ActsAsFlinn, the difference between JSON-P and AJACSS is that the later is just read-only data.

]]> By: Jon Crosby http://www.engineyard.com/blog/2009/cross-domain-data-with-rack-and-rails/comment-page-1/#comment-337 Jon Crosby Fri, 29 May 2009 04:58:04 +0000 http://www.engineyard.com/blog/?p=1111#comment-337 Dr Nic, I should have explained more clearly in the original post. The encoding is done on the side of the data provider so that all clients can access it without needing to set up their own proxies. Dr Nic, I should have explained more clearly in the original post. The encoding is done on the side of the data provider so that all clients can access it without needing to set up their own proxies.

]]> By: ActsAsFlinn http://www.engineyard.com/blog/2009/cross-domain-data-with-rack-and-rails/comment-page-1/#comment-336 ActsAsFlinn Fri, 29 May 2009 01:22:23 +0000 http://www.engineyard.com/blog/?p=1111#comment-336 I don't see the objection to JSON-P. I'm not going to trust a partner more if they are using AJACSS over JSON-P. If I don't trust partner I'm not going to embed their service data on my pages. There are old precedents for providing features/widgets/ads via external javascript includes. Also, isn't IE6 susceptible to XSS attack via CSS? One thing is certain browsers need to provide a cross-domain non-eval'd data source mechanism. Why wasn't this addressed in HTML5? Seems like a bigger issue than web sockets. I don't see the objection to JSON-P. I'm not going to trust a partner more if they are using AJACSS over JSON-P. If I don't trust partner I'm not going to embed their service data on my pages. There are old precedents for providing features/widgets/ads via external javascript includes.

Also, isn't IE6 susceptible to XSS attack via CSS?

One thing is certain browsers need to provide a cross-domain non-eval'd data source mechanism. Why wasn't this addressed in HTML5? Seems like a bigger issue than web sockets.

]]>