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
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 | |
|
|
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.
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
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.