The LiveJournal FAQ states

All journals on LiveJournal have an RSS feed, located at a URL of the form http://www.livejournal.com/users/exampleusername/data/rss/, where "exampleusername" is replaced by your username.

Only the 25 most recent entries are displayed on this RSS feed. Protected entries are visible if the user requesting the RSS feed is able to authenticate with LiveJournal and has permission to see the entries. For example, if you view your RSS feed in your browser while logged in, you will see all your most recent entries in it. However, someone who is not logged in, or someone you do not list as a friend, would not be able to see any protected entries in the feed. For most RSS aggregators and newsreaders, this will mean that only public entries are included. This is because they generally do not provide any means of cookie authentication.

I can't tell which stuns me more the fact that LiveJournal implemented an "authentication" mechanism that requires RSS aggregators to reuse steal cookies from your browser instead of using well defined HTTP authentication mechanisms or the fact that they implemented this ghetto authentication mechanism knowing full well that most aggregators don't support it.

Based on my reading of the FAQ, a user has to login via the website then somehow pass the cookie sent from the server in the HTTP response to their aggregator of choice which then uses this cookie in HTTP requests for the RSS feed?  All this, instead of password protecting the RSS feed using standard web practices?

We just got a feature request to somehow support this in RSS Bandit but it seems so wrong to encourage this broken design chosen by LiveJournal that I'm tempted to refuse the request. Is there anyone else subscribed to a LiveJournal RSS feed that thinks having this feature (the ability to view protected LiveJournal feeds) is important? So far, I believe this is the first LiveJournal specific request we've gotten.


 

Tuesday, 25 November 2003 18:19:03 (GMT Standard Time, UTC+00:00)
Actually, part of the login process allows you to make the cookie last beyond the browser session, so that the next time you visit the page you're already logged in.

So assuming that someone has set their cookie to be persistent and that you can find the cookie associated with the site (I think Torsten had some code on his blog that dealt with this) then it might be possible?

I won't say that the design is broken, but that IMO the reason they use cookies and not HTTP Auth is because they need to support a wide range of platforms/browsers, some of which might not support it (whereas presumably most browsers, including the obscure ones, support cookies).

I have some free time these days, so I might change my local copy of RSS Bandit and see whether that is an acceptable solution.
Tuesday, 25 November 2003 18:39:22 (GMT Standard Time, UTC+00:00)
Seems to me that they want to do what's called "forms authentication" in .NET. It's not a question of hijacking a cookie, the problem is that there's no standard API for forms authentication schemes, it's just a HTML form submission. Personally, I'm with you: providing only forms authentication is dumb and restrictive. I think that they could have provided both mechanisms, using an HTML form for fallback. I'm not sure I even by the argument that cookies are better supported than HTTP authentication, IIRC, basic and digest have been supported since IE3 and NS3, certainly since version 4 of each, and I'm sure Opera does HTTP auth. Anyway, I'm pretty sure that LJ users would conform to the general browser usage profile, so supporting ancient or rare browsers probably isn't really an issue.
Tuesday, 25 November 2003 20:56:42 (GMT Standard Time, UTC+00:00)
Whatever we think of how Live Journal implemented a feature, the question remains, do you implement a feature in your software to interact with their feature?

I am both a Live Journal user and a RSS Bandit user and I could care less. I see all I want already. Since you have received at least one request others seem to care.

As for standards and design decisions: there is always a reason for the apparently unreasonable thing someone else has done. [Wink]
Wednesday, 26 November 2003 03:54:28 (GMT Standard Time, UTC+00:00)
I'd think a better approach than having all RSS aggregators conform to LiveJournal is for LiveJournal to better conform to the HTTP specification. Let LiveJournal change itself to use HTTP auth.
Friday, 28 November 2003 00:56:00 (GMT Standard Time, UTC+00:00)
I suspect it's more likely that LiveJournal's RSS feeds accidentally support the LJ authentication mechanism just because they are generated by the same code which generates the normal HTML journal views.

I'm sure there'd be no objection to making the RSS feeds support HTTP auth, although BradFitz would probably take issue with doing Basic auth over an unencrypted link and require digest auth.

All it really requires is for someone to submit a patch.
John
Friday, 28 November 2003 18:55:53 (GMT Standard Time, UTC+00:00)
Feed Demon (http://www.bradsoft.com/feeddemon/) currently does this, and it's pretty useful for sites that provide RSS feeds and use persistent cookies for authentication (like LJ).
Joe
Comments are closed.