Anwiki CMS

Anwiki CMS : the first wiki/CMS dedicated to multilingual contents
| Tasklist |

FS#28 - Persistant session for RSS

Attached to Project: Anwiki CMS
Opened by anw (anw) - Saturday, 04 April 2009, 16:58 GMT
Task Type Improvement
Category Drivers → Sessions drivers
Status New
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version Anwiki 0.1.0 alpha 1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


RSS are currently based on users session. When session expires, RSS feeds are lost.
RSS feeds are related to users session because they are based on user's permissions.

We could maybe create a "degraded session key" only used for limited read-only access such as RSS.
This key would be given in RSS feed URL, so that RSS feed would still be valid even when user's session expires.
This task depends upon

Comment by Wladimir Palant (trev) - Thursday, 14 October 2010, 09:30 GMT
I was about to file a duplicate of this bug. Unfortunately, the RSS feeds currently aren't really usable - most of the times the RSS feed reader is an independent application and doesn't even have user's session in the first place. A session key in the feed URL would be the only way to reliably grant access to RSS feeds.

Note that this doesn't really require new sessions in the database. There is no reason why this "session key" should ever expire or be invalidated. So it could be a combination of the user's account ID and a checksum. The checksum would be built from a server-specific auto-generated secret key (stored in _override/global/global/global.cfg.php) and the account ID, e.g. md5(secret . '|' . userID). Including action name is also possible - then the key would grant access only to a specific RSS feed, not all of them. An attacker won't be able to generate the checksum because he doesn't know the secret key. The server will however be able to verify the checksum simply by re-calculating it - if the two checksums match the session key is valid, no database accesses necessary.
Comment by anw (anw) - Thursday, 14 October 2010, 23:40 GMT
This sounds good, it may be implemented on sessions level for providing a generic session-access mechanism, restricted to a specific action and/or specific contents.