History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: CIB-245
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Daniel Ostermeier
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Pulse

Provide basic authentication for rss feed links.

Created: 21/Mar/06 06:44 PM   Updated: 11/Dec/08 05:48 AM
Component/s: Security, Rss
Affects Version/s: 0.3.1
Fix Version/s: x.x


 Description  « Hide
We need to authenticate rss feed requests.

One option is to use the token manager and its authenticated tokens. There are some open questions however:
a) persistence of tokens. if the server restarts, then the rss feeds should not be invalidated.
b) what timeout should we used for tokens, remembering that we dont want to end up with a 'memory leak' because we are keeping the tokens for too long.

We would need to work out a clean way to tie this into acegi.

 All   Comments   Change History      Sort Order:
Daniel Ostermeier - 03/Apr/06 10:44 AM
Token based authentication for RSS feeds has a number of associated problems. In particular, when do we expire the token?

The token has to be expired. The sooner, the less chance there is of someone else using that token. However, the token needs to be valid for at least as long as you would expect between feed requests. Normally this would not be overly long - 5mins - 2hours. Things get a little more complicated if the server goes down. We dont want a situation where extended server downtime would invalidate all of the systems RSS feeds.

So maybe token based authentication is not the most appropriate way to go.

RSS feed readers should provide basic authentication support, so we could use that instead, but simply applying the correct acegi filters to the rss request.

Daniel Ostermeier - 03/Apr/06 10:45 AM
Updating this improvement request to implement basic authentication for RSS links rather then token based authentication.

Daniel Ostermeier - 03/Apr/06 11:35 AM
moved to 1.0 release. Not necessary for 0.4

Daniel Ostermeier - 24/Jan/07 11:48 PM
1.2.x is now for bug fixes only as 2.0 development is making major incompatible code changes to the core, making support for development on two branches impractical.

Daniel Ostermeier - 11/Dec/08 05:48 AM
Trying to clean things up a little. We currently have a couple of very large buckets of tasks that are really not indications of our scheduling. What I am doing is for starters, moving all of the 2.x. items into x.x to indicate that they have not been scheduled. We can later go through these and pick up with ones that we intend to complete for an upcoming release.