I should note there are security issues with making that api key visible to users. If someone has it, they can do anything that the underlying user account can do. It would be much better to fetch the RSS server side using the key then only exposing the resulting feed.
Also, be especially careful not to generate an “All Users” key for this. If someone gets that key they can do anything as any user on your site. So just be extra careful
We are having the issue that the RSS feeds do not work with an api_key if the categories have read restrictions, even if the api_key is valid for a user that should be able to access the category.
Yes they do! @blake any thoughts about how people will do private RSS feeds in the current world. Do browsers/rss feed things support custom headers for auth?
This is a pretty rare use case, but would be nice if we had a workaround.
The only auth related thing to rss is support for url based basic auth like https://user:password@www.example.com (which we don’t have support for) or something like what we currently support with api_key & api_username in the url.
While it would have been nice to completely retire url based auth I think the way forward so that we still have support for private rss is to only allow this type of auth for topic/category feeds, and then later we can also add support for readonly api keys.
The problem is also that rss readers usually only have a single url field for adding a feed, so even if rss had support for headers, readers don’t have a place to add credentials to a header.
One idea here related to some of @david’s scoping work is that we could make a user api key that is tightly scoped to a single RSS feed, that way the surface area is low, and in cases like that where we have an ultra scoped user api key we could allow it without headers (a column on user_api_key to say this key is can use GET for auth).
The challenges here are:
We don’t have a mechanism for users to generate user api keys, we would have to build something for the RSS use case which would involve some new UX, not sure where we would even add it, in the user profile maybe, I don’t know.
We don’t have a mechanism to scope down just to one specific RSS feed which we would have to add
We don’t have a flag for “allowed user API key” via URL GET params which would be required for this
Overall I see this as something we could solve but we are probably looking at a week or two of work here to get it working just right.
The upside is that some of this work is work we want to do regardless of RSS, but the downside is that some of the work is very tightly coupled to RSS and there are very few people who use this feature these days.
Up to @codinghorror I guess to choose how we want to prioritize this.
I’ve got WordPress and Discourse integrated with WordPress doing SSO. I’m generating a sidebar of recent posts in WordPress using RSS feeds from a number of categories using the API so would love to maintain the URL auth mechanism for that. Otherwise I’m going to have to get my hands dirty writing a custom widget to try to implement the header auth option. So I guess I’m a +1 for the few people that use it.
It seems that the fetching the rss with api key must specify a accepting header to fetch the right data.
If I fetch the rss without specifying the accept header like curl https://bbs.example.com/c/cat.rss?api_key=KEY could result to a < HTTP/1.1 404 Not Found page.
However, with specifying the accept-header, the xml for the rss could be fetched correctly. For instance: