[Update: more results]
[Update: some results left as comments; and more.]
Thanks to everyone who posted comments on my Password-Protected RSS challenge three weeks ago. It turned out that the vast majority of feed readers can handle HTTP basic authentication for feeds.
Of course, if a feed holds important, confidential information, basic authentication over HTTP won’t be enough — you need to be able to use HTTPS to encrypt your password and data in transit. I do not have an SSL/TLS certificate for megginson.com, so I moved my test over to a different site, newmatica.com. Here’s the URL for the same RSS file, this time over HTTPS (the user id and password are still “guest”):
Will your feed reader allow you to subscribe to a password-protected RSS 2.0 feed when SSL/TLS is involved? Here’s what I’ve tested:
- Prompts for a username and password, and stores the password on disk as clear text.
- Reports no feed found. However, will read the RSS file if the username and password are encoded in the URL, i.e.
- Fails: HTTPS not yet supported.
- Reports a 401 HTTP error (authorization required). Strips the username and password from the URL if they are provided.
Once again, I’ll be grateful for comments about other RSS readers.
Update: reports from readers
Once again, thanks to readers who have left reports in comments. Here are the results so far:
- John Cowan and Tim Howland report success.
- Peter Lacey reports success.
- Brent Simmons reports success.
- RSS Bandit
- Dare Obasanjo reports success.
- Opera (8.0.2)
- Tony Coates reports success.
- KDE Akregator
- Douglas reports success.
- Brian R. Barker reports success.
- Silas Hundt reports success, with username and password saved to the keychain.
NetNewsWire prompts for username/password, says the password will be stored in the Keychain (the right thing to do on a mac), but then doesn’t show the feed contents. (You’re sure there’s something there David?)
Tim: you can try opening the RSS file directly in Firefox or Safari to confirm that it’s there.
David: Direct reference doesn’t work either, and that’s because something in your publishing chain is awry.
After doing a View Source, it turns out that the relevant href attribute has backslashes before the quotation marks around its value. This causes Firefox to interpret the backslashes as if they were *inside* the quotation marks, making the URI a relative reference. The resolved absolute URI becomes http://www.megginson.com/blogs/quoderat/archives/2005/08/20/ssltls-rss-challenge/%5C%22https://www.newmatica.com/test/blog.rss%5C%22
So find out where the backslashes are coming from.
I patched the URI in Sage by hand, and it does work. I got a username/password demand from newmatica.com to load the feed, and another one from megginson.com to read the first item. So all is well, as would be expected.
Sage gave no visible indication that it was fetching secure content.
John (and Tim):
Thanks for the problem reports. I’ve fixed up the blog page (unfortunately, WordPress sometimes tries to fix what it considers to be problems with the markup), and the link should be OK now.
Once again, NewsFire continues to rock. It prompted for username and password, and displayed the two entries just fine.
I tried it in NetNewsWire — it prompted for a username and password, then it displayed the two items (“Sample Item” and “Second Sample Item.”)
I don’t know why it didn’t work for Tim, but I suspect a refresh might fix it.
It was probably the problem John Cowan pointed out in his comments. I fixed those after Tim tried NNW.
Works fine with RSS Bandit if you provide the username and password.
Looks like Sage (Firefox extension) works perfectly.
Opera 8.0.2 works (for both this and the former test).
FeedDemon 1.5 prompts for userid and password, and shows two items in the feed.
KDE’s built-in RSS reader, Akregator, works fine for https based RSS feeds.
Safari handles ’em both. Of course stores pass and ID in keychain