Skip to Content.
Sympa Menu

devel - Re: [sympa-dev] private RSS feeds

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: Olivier Salaün - CRU <address@concealed>
  • To: address@concealed
  • Subject: Re: [sympa-dev] private RSS feeds
  • Date: Fri, 03 Mar 2006 12:14:59 +0100

Sympa's RSS feed is currently just a public feed (though authorization scenarios are applied, therefore REMOTE_HOST can be used).
If there is interest for a new "private RSS" feature, I suggest we add a new entry in our wiki : http://www.sympa.org/wiki/doku.php?id=project_direction

We also have some improvements (especially regarding characters encoding) to make in the way Sympa provides RSS.

John-Paul Robinson wrote:
How do RSS feeds deal with HTTP authentication?  If a URL for a feed is 
protected by this is there a prescribed behavior?  More specifically, how 
does an RSS reader deal with redirection, if it occurs?

If RSS is really cookie-less then the above won't work, so what about a 
session number in the feed?  Sessions could time-out so potential exposure 
can be controlled but how does RSS deal with things like login to even 
handle a session URL?

Here are a couple of URLs about private rss feeds:

Older discussion:

  http://labs.silverorange.com/archives/2003/july/privaterss

How Radio UserLand does them

  http://radio.userland.com/stories/storyReader$7001 

I'm not finding any clear statements on how this should be handled.  If 
there is to be passwords/sessionids in URLs they really need to be 
short-lived in order to keep things private.  This has complexities of 
it's own.  

Another option might be to use SSL-based authentication... while that 
would probably work (given an RSS client supports it), it would have it's 
one set of deployment issues.

~jpr

On Thu, 2 Mar 2006, Serge wrote:

  
The way we manage authentication in Sympa is going to change totally as 
described in the page 
http://www.sympa.org/wiki/doku.php?id=project_direction . But this will 
not solve the problem.
Because RSS readers to not manage cookies, the only solution could be 
collect authentication information from the URL ( a part of the URL 
could be some personnal secret sent to a particular authenticated user 
). In fact, we could introduce the sympa_user cookie value in the URL.  
Unfortunitly, this secret URL may become public as soon as some user 
brodcast this URL to some french or copy it to a page which is collected 
by google ...

Any proposition ?
Serge

    
  




Archive powered by MHonArc 2.6.19+.

Top of Page