Privacy, authentication, and RSS/atom feeds - current state + plans
06-September-2005
permalink trackbacks (1) email this-
Nnw-Authenticate-Egcrf
[ Download ]
(NNW-authenticate-EGCRF.jpg
-
70.67 Kb
)
Preview
I'm about to post a short overview of our plans for dealing with trackback spam, and realised that before going into those measures, I should first review the behaviour - current and planned - regarding authenication for RSS/atom in KNotes.
First - what is the issue? Basically, manegers can use the permissions form for a KNotes weblog to make the blog readable only to certain members. Likewise, a parent Plone folder could have been given a workflow state of 'private'. In either case, through-the-web pageloading requires authentication by a member with the correct permissions.
But what about the RSS/atom feeds for that private, members-only weblog? If a snoopy and savvy person wanted to type in the url for an RSS feed for the private weblog, surely they should not be able to read content in their news-reader which they could not read in their browser?
No, they should not. And at least some news-reading clients respect that. For instance, NetNewsWire offers username/password properties for a subscription, and will present an interface for entering them if the subscription demands it with its http response header.
And KNotes' RSS and atom feeds will not return content unless given an appropriate username/password when the request is made on a zope object which would require authentication for viewing through the web. Try it... if you subscribe in netnewswire to a private weblog, you'll have to enter a username an password ( in the get-info dialog for the subscription ) in order to fetch content.
BUT there is still work to be done:
- Demand authentication nicely
- We need to have the private feeds send back an authentication demand header rather than the error they currently do. This is a very small job but needs to be scheduled,
- Return '' for nested private content in public feeds
More important by far: If you subscribe to a KNotes feed with '?include_discussion=1' -- ie you want to get nested content in the feed -- you can read nested private content. At the moment, privacy is only 'ert' at the level of the object the feed is called on. The content of the feed is assembled with an SQL query, so zope-wise permissions are not taken into consideration when grabbing the item content (and we definitely want the SQL speed). What we need to do is to impose a very simple policy: content which is not public through the web should not appear as nested content in any feed.
This policy would be draconian but safe. The SQL database kndiscussion table rows can 'know' whether or not "some" authentication is required (but cannot of course encapsulate zope's complex acquirable permissions, so cannot know whether the current request should authenticate against a row). But, since a row can know that its content is not public, it can have its feed content an empty string except when called directly on its parent object... in other words, a different query would have to be called for the non-nesting case
As you can see, some changes to the SQL data model are required in order to prevent non-public content from appearing in feeds other than those called directly on its parent. That means work, and will have to wait.
In the meantime, beware that private content could be sniffed by savvy snoopers. Personally, I would resist privacy anyway, but I appreciate that it is very important to some of our own users - and we will attempt to effect correct behaviour soon after 'release' :o)
1 Trackbacks (links from other content)
1 Privacy, authentication, and RSS/atom feeds - current state + plans
Linking and trackbacks
When linking to this weblog entry, please use the 'permalink', which is http://www.knownet.com/Members/mmalloch/blog/entries/5332512494
){kind=link}