As far as I can see, the majority of RSS feeds exposed on most sites provide access to very generic, summary information. I’m quite surprised that RSS hasn’t really been embraced for the kinds of thing for which it would be most suited - i.e. bringing you highly targeted, highly relevant information based on some prior knowledge of who you are.
I would love to be able to give a list of my favourite bands, and subscribe to a feed of gigs they are planning in my area; or give a list of my preferred cinemas, and find out whenever a new film is showing at any of them.
Once you are providing more personal feeds, then authentication becomes an issue. There is fairly widespread support in aggregators for both SSL and Basic Authentication, but this can be overkill for certain situations.
The data we are exposing is not particularly sensitive, and it would be a real pain for a user who has authenticated with the main site to be challenged when they subscribe to a feed. Instead, the approach we’ve taken in…
- When a private feed is available on a page, the meta tag in the head includes a token on the querystring for the feed URL that is generated based on the currently authenticated user
- When serving up a private feed for a particular user, we expect the token on the querystring, and bounce the request if either the token is missing, or is incorrect
This means…
- An authenticated user can subscribe directly to a feed without an additional challenge
- If you know the URL to your own feed, you can’t get access to others simply by changing the feed URL
- The mechanism used for feed authentication doesn’t expose anything related to authentication on the main site
We’re exposed to the feed URL and token being sniffed on the wire, but unless the content is particularly sensitive this seems like a suitable, practical approach to ensuring some degree of privacy without introducing complexity and barriers to subscription.