New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add CORS headers to the RSS feed #4663

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
6 participants
@adamcooke

adamcooke commented Dec 17, 2014

This PR adds cross origin headers to the RSS feed thus allowing it to be accessible by other webpages which wish to pull the feed using AJAX. This is useful if you want to include the latest X posts from your blog on an external site.

There are no particular security concerns to be worried about here as it only allows the GET method and nothing in the rss action changes any data.

@adamcooke

This comment has been minimized.

Show comment
Hide comment
@adamcooke

adamcooke Dec 17, 2014

The error in this build is nothing to do with me. The build simply doesn't work in master at the moment.

adamcooke commented Dec 17, 2014

The error in this build is nothing to do with me. The build simply doesn't work in master at the moment.

@adamcooke

This comment has been minimized.

Show comment
Hide comment
@adamcooke

adamcooke Dec 17, 2014

If you wanted to see why this is an issue you can use this page which renders the RSS feed using JQuery. If you set the URL to a blog which doesn't have these headers, you'll find an error. If you use this branch, works beautifully (http://s.adamcooke.io/14/ul1xa.png).

https://gist.github.com/adamcooke/16dd35606f8796dad315

adamcooke commented Dec 17, 2014

If you wanted to see why this is an issue you can use this page which renders the RSS feed using JQuery. If you set the URL to a blog which doesn't have these headers, you'll find an error. If you use this branch, works beautifully (http://s.adamcooke.io/14/ul1xa.png).

https://gist.github.com/adamcooke/16dd35606f8796dad315

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Dec 17, 2014

Member

The use case you're suggesting here is being able to get your latest X posts on an external site of your choice, but by specifying global CORS headers, what you're actually allowing for is anyone to show any Ghost blog's latest X posts on any site. That's an enormous leap to add to Ghost core, and I don't think there's a justification for it.

The JSON API is intended to allow for this sort of thing in a controlled way (via OAuth clients) which means that the owner of the blog would always have absolute control over who can do what with their content.

Member

ErisDS commented Dec 17, 2014

The use case you're suggesting here is being able to get your latest X posts on an external site of your choice, but by specifying global CORS headers, what you're actually allowing for is anyone to show any Ghost blog's latest X posts on any site. That's an enormous leap to add to Ghost core, and I don't think there's a justification for it.

The JSON API is intended to allow for this sort of thing in a controlled way (via OAuth clients) which means that the owner of the blog would always have absolute control over who can do what with their content.

@adamcooke

This comment has been minimized.

Show comment
Hide comment
@adamcooke

adamcooke Dec 17, 2014

To use the JSON API would suggest some form of authentication which would not be possible when trying to render posts onto another site anonymously. I wouldn't want to include API credentials in my open javascript. The use case here is displaying your blog posts on your homepage without any authentication.

You already provide the blog posts publicly (both in HTML & XML/RSS) so there is no new information being provided. Adding these headers simply is designed to allow ANY client to access the feed rather than just non-web-browsers (which is how it stands now).

Right now, anyone can render any blog posts onto their website with no effort at all by simply proxying the RSS data through their backend. In fact, it only took me a few minutes to write a simple app to get all the blog posts from Ghost's blog and render them in HTML - http://ghost-posts.vdtapp.com.

By not allowing browsers to access the feed, you cause people to need to proxy the data which is some cases might not be possible. Specifically, in my case, I want to render some other posts within the template of another Ghost blog where I don't have access to proxy the RSS data through the app without modifying the Ghost source.

I do hope you'll reconsider this because I really don't understand why this is an enormous leap. You have an API (the RSS feed) designed to be accessed by machines and it cannot be used by a large proportion of HTTP clients out there. 😢

adamcooke commented Dec 17, 2014

To use the JSON API would suggest some form of authentication which would not be possible when trying to render posts onto another site anonymously. I wouldn't want to include API credentials in my open javascript. The use case here is displaying your blog posts on your homepage without any authentication.

You already provide the blog posts publicly (both in HTML & XML/RSS) so there is no new information being provided. Adding these headers simply is designed to allow ANY client to access the feed rather than just non-web-browsers (which is how it stands now).

Right now, anyone can render any blog posts onto their website with no effort at all by simply proxying the RSS data through their backend. In fact, it only took me a few minutes to write a simple app to get all the blog posts from Ghost's blog and render them in HTML - http://ghost-posts.vdtapp.com.

By not allowing browsers to access the feed, you cause people to need to proxy the data which is some cases might not be possible. Specifically, in my case, I want to render some other posts within the template of another Ghost blog where I don't have access to proxy the RSS data through the app without modifying the Ghost source.

I do hope you'll reconsider this because I really don't understand why this is an enormous leap. You have an API (the RSS feed) designed to be accessed by machines and it cannot be used by a large proportion of HTTP clients out there. 😢

@adamcooke

This comment has been minimized.

Show comment
Hide comment
@adamcooke

adamcooke Dec 19, 2014

Any more thoughts about this?

adamcooke commented Dec 19, 2014

Any more thoughts about this?

@JohnONolan

This comment has been minimized.

Show comment
Hide comment
@JohnONolan

JohnONolan Dec 19, 2014

Member

I find the use-case to be both valid and common.

RSS is public and I don't see any privacy issue. The issue of not wanting to allow RSS feeds to be embedded anywhere by anyone is not one that not-merging-this-PR solves in any way. People can (and do) fundamentally already scrape feeds, web pages and data sources and republish content. Making it harder to do doesn't accomplish anything. Whereas as making it easier to do does have real benefits.

The JSON API is intended for complex data access and manipulation which can (and should) require authentication. This, however, is extremely light touch, and basically just a utility function to make use of a natural feed which the blog already provides.

@ErisDS your call, but I'm pretty in favour of this.

Member

JohnONolan commented Dec 19, 2014

I find the use-case to be both valid and common.

RSS is public and I don't see any privacy issue. The issue of not wanting to allow RSS feeds to be embedded anywhere by anyone is not one that not-merging-this-PR solves in any way. People can (and do) fundamentally already scrape feeds, web pages and data sources and republish content. Making it harder to do doesn't accomplish anything. Whereas as making it easier to do does have real benefits.

The JSON API is intended for complex data access and manipulation which can (and should) require authentication. This, however, is extremely light touch, and basically just a utility function to make use of a natural feed which the blog already provides.

@ErisDS your call, but I'm pretty in favour of this.

@joeldrapper

This comment has been minimized.

Show comment
Hide comment
@joeldrapper

joeldrapper Jan 9, 2015

Contributor

I thought the whole point of RSS feeds is that they can be easily scraped.

Contributor

joeldrapper commented Jan 9, 2015

I thought the whole point of RSS feeds is that they can be easily scraped.

@helxsz

This comment has been minimized.

Show comment
Hide comment
@helxsz

helxsz Jan 9, 2015

The ajax works for me . But when I tried to use the angular.js to work on the same.

        $http({
              url:   "http://localhost:2368/rss/", 
              method: "GET",
              headers: {"Accept":'application/json'}           
          }).success(function(blogs) {
            })
            .error(function(err){
            }) 

I still get the issue --
XMLHttpRequest cannot load http://localhost:2368/rss/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access.

Why is it ok for Ajax not Angular.js, I am using chrome browser

helxsz commented Jan 9, 2015

The ajax works for me . But when I tried to use the angular.js to work on the same.

        $http({
              url:   "http://localhost:2368/rss/", 
              method: "GET",
              headers: {"Accept":'application/json'}           
          }).success(function(blogs) {
            })
            .error(function(err){
            }) 

I still get the issue --
XMLHttpRequest cannot load http://localhost:2368/rss/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access.

Why is it ok for Ajax not Angular.js, I am using chrome browser

@adamcooke adamcooke closed this Jan 13, 2015

@foggy1

This comment has been minimized.

Show comment
Hide comment
@foggy1

foggy1 Jul 1, 2018

I'm aware this is an old PR, and that the infrastructure is different now, but I think this is worth revisiting. Allowing an RSS endpoint to be accessible from anywhere does not seem unreasonable, since that's the entire point of RSS in the first place.

If anything, not allowing CORS on an /rss endpoint is actually preventing that endpoint from working as it should. RSS exists to be fetched by whomever, it shouldn't be locked down like the other parts of the blog.

foggy1 commented Jul 1, 2018

I'm aware this is an old PR, and that the infrastructure is different now, but I think this is worth revisiting. Allowing an RSS endpoint to be accessible from anywhere does not seem unreasonable, since that's the entire point of RSS in the first place.

If anything, not allowing CORS on an /rss endpoint is actually preventing that endpoint from working as it should. RSS exists to be fetched by whomever, it shouldn't be locked down like the other parts of the blog.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment