[geeklog-devel] Recent and remaining work on the webservices

[Dirk Haun]

This post is mostly intended for Ramnath (Hi!) but I thought I'd send it
to the list, since it also contains some information on implementation
details.

As you may have seen, I have been working a bit on the webservices in
Geeklog, as I ran into a few issues while preparing for my Atompub
presentation[1] earlier this week.

Here's a short summary of what I've done:

- Fixed WS_getContent for XHTML content - it only returned the first
node, i.e. typically only the first paragraph of an entry. That's a bug
I introduced some time ago.

- Added an <app:edited> element to all entries. That's something the APE
was complaining about. It's simply the same timestamp as in <atom:updated>.

- Reduced the number of Geeklog-specific elements in an entry, where
possible. For example, the expire_date is only valid when 'statuscode'
is set to ARCHIVE or DELETE_ON_EXPIRE so we don't need to send it when
that's not the case.

- Added a verbose logging option ($WS_VERBOSE) which logs some things to
error.log (for debugging)

- Implemented a speedlimit for failed logins. I accidentally fed the APE
with a wrong password and it kept trying to log in over and over.

- Even though the RFC only says that the server SHOULD return the
created entry after a POST, the APE insisted on it (it actually died
when wasn't there). So I've implemented that.


With these changes and a special local version where story IDs can have
up to 80 characters, Geeklog now passes most of the APEs tests (except
for one, see below).


Remaining issues:

- As discussed: The service document (introspection) should return two
collections, one for stories and one for static pages.

- Also as discussed: Long IDs are a problem. At least the APE will now
happily pick up and use changed IDs (we replace the colon and comma it
uses in its IDs), so once we've figured out how to assign and return
short IDs, it should accept those, too.

- The remaining error: The APE attempts a second POST for an already
existing entry. I'm not sure what we're supposed to do then - there
doesn't seem to be anything about this case in the RFC.

- We probably need more speedlimits in the webservices code, just like
we have in the normal story submission code. I can look into that.

- Haven't looked into the details, but we're returning stories that have
the draft flag set for non-authorized GET requests. That's a bug - only
story admins should be able to see draft stories.

I assume the only proper way to fix this is to require a login for _any_
GET requests. All Atompub clients that I've tried so far will only try
to log in after they get an HTTP 401 status code. So if we only returned
non-draft stories after a GET without a login, they would never see the
draft stories. The same actually applies to other permissions, e.g.
stories that are only visible to certain user groups.

I think we can safely assume that the webservices are only meant to be
used by registered users (as opposed to anonymous users) and that we can
therefore require them to log in.

bye, Dirk

[1] <http://geeklog.info/article.php/atompub-vortrag>


-- 
http://www.geeklog.net/
http://geeklog.info/