Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pudge (1)

  (email not shown publicly)
AOL IM: Crimethnk (Add Buddy, Send Message)

I run this joint, see?

Journal of pudge (1)

Monday December 29, 2003
05:26 PM

Personalized RSS, New Authentication

[ #16542 ]

Updated: See followup.

We've wanted to do personalized RSS feeds in Slash for some time, and we finally got around to starting them. On Slashdot they may be subscriber-only features, but for now, on, they will be available to any registered user.

It differs from the normal RSS feed at in that it follows your own preferences for the index page, and it gives you the complete "introtext" of the article (for long articles, which have additional text in "bodytext", you still need to click to receive the full content). And if you use SSL to access the site, your RSS will contain SSL links, too.

All you do is add "content_type=rss" to the request, for example:

That assumes, of course, that your RSS reader can do cookies, and that it has properly authenticated you. Most don't, so we needed a way to authenticate you. For some time, we've wanted to make user authentication better, because right now we put an MD5 digest of your password in your cookie, which isn't very secure. So we created the logtoken.

The logtoken is an arbitrary string that has several benefits over the previous cookie. First, there is no way to "crack" it to recover the original password. While this is difficult with MD5 digests, it is somewhat possible, using brute force. Now it is impossible.

Also, the logtoken will be tied to your class B address, so someone can only use your cookie, if intercepted, if coming from the same class B network. Now, this will cause problems for some people who use the same computer at multiple locations (like many laptop users); perhaps, in the future, we can allow multiple cookies, or allow a user to skip the subnet check. Or maybe we'll give up and throw it out. :-) Please provide feedback; I am leaning toward allowing users to skip the subnet check.

A benefit of all this is that the mere act of logging out will invalidate the logtoken, but not your password. So if you fear your logtoken is stolen, you can log out. Of course, chances are you initially sent your password over cleartext to log in anyway, but not to fear, SSL logins will be coming soonish (on Slashdot anyway ... not sure about use Perl; or other OSDN Slash sites). So you can be at a public terminal, log in over SSL, and then work over plaintext, but with a logtoken cookie being sent/received. When finished, log out, and your logtoken is destroyed.

But since it is tied only to that subnet, your logtoken at home is still valid, unless you log out at home. You can delete ALL your logtokens by changing your password (even by "changing" it to the same thing as it currently is).

So how does this fit in with RSS? Just add "logtoken=$logtoken" to the request:

And since the logtoken won't change, unless you log out in that subnet, or change your password, you won't need to change the URL in your RSS reader very often. Well, there is a one-year expiration on the logtoken, just like on your cookie. We might make it so when you re-log-in, your expiration date is reset if you get the existing logtoken (e.g., in a case where you logged in with a second browser on the same subnet, getting a new cookie with the previously existing logtoken for that subnet).

Right now, if you get the logtoken wrong, you get redirected to the home page. We may change this, so you get an error message in RSS if you requested RSS, or somesuch.

There's a URL giving you your logtoken value -- the whole RSS link, actually -- on the top of the home page.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Well, I use approximately five different wireless connections in any given week, each of which carrying its own A block. While it's a rather nifty idea to limit things to an IP address block, um, it sounds relatively ineffective for roaming power users.

    For articles that have more content when you click "Read more", I'd like the option to get that content in the RSS feed.
  • Looks great in the reader, sans the missing content. Forgot to mention that.
    • We may add it, but not in the plans right now. It should be simple enough to add, but other things have priority (like dealing with the class B subnet thing :-).
  • RSS is GOOD! But, the FAQ incorrectly gives this URL for journal feeds:

    I think it should be something like:

    Also the feed is gzipped, but firefox's live bookmarks seems unable to handle that. Perhaps I'm missing something I can do to the URL or to firefox.

    Hip, hip! Chin up! None of that how's-your-father nonesense here!