Dinah

Login!
Register as a new userLost password?

for Project:

FS#72 — Personalised RSS

Attached to Project— Dinah
Opened by icklenewt (icklenewt) - Thursday, 18 January 2007, 10:12PM
Last edited by icklenewt (icklenewt) - Thursday, 18 January 2007, 10:16PM
Feature Request
Backend / Core
New
No-one
All
Low
Normal
Development
Undecided
Undecided
0%
Original Request:


quite a few sites (some torrent ones i use) support an rss url which includes a 'token' which uniquely identifies the user. i guess its some kind of hash of their username and password.

it allows me to see feeds which i have the perms to see.

is there any interest in such a cyberarmy feed which exposes forum posts (including those in non public forums) by using some kind of user identification.

====================================================================================================================


See attached comment with implementation input from theDigitalPoet.
This task depends upon

This task blocks these from closing
Comment by icklenewt (icklenewt) - Thursday, 18 January 2007, 10:16PM

DigitalPoet has given the following input/advice on this issue:

=====================================================
It sounds like a good idea to me. It would be wise to enforce HTTPS for all feeds, this would ensure privacy of the feed data and also the URL containing the 'token'.

The token itself may not be enough, the username would have to be provided in some form also because otherwise a bruteforce on the hash would be required to determine who the user is.

You may want to consider adding a structure into dinah that will allow multiple passwords to be attached to a user. Something like...

username | password_category | password
------------------------------------------------------------
thedigitalpoet | rss | somepass
thedigitalpoet | osix | someotherpass
thedigitalpoet | cau | againanotherpass

For now, just the rss would be used (which would form BB's 'token'), this would mean that a user's master password (or any brutable hash) does not need to be entered into third party software, so any comprimise is not total and would not allow an attacker to take over the account (by logging on, changing password and email).

This structure would also be extendable (as I have hinted to above) in that it could be built on to provide other passes which could be used to verify a dinah users from any external source without comprimising any the master password or any other service.
=====================================================

This sounds very promising.