Announcing XML::Atom
I've released XML::Atom, a Perl implementation of all things Atom. The goal for XML::Atom is to provide an implementation of the syndication feed format, the API, and the archiving format planned for Atom. Currently, it provides support for the feed format, and an implementation of a client for the API.
The API implementation in XML::Atom implements (most of) the API described in Joe Gregorio's Atom API Revision 7, using the WSS authentication mechanism described here. By default, the implementation uses the REST format of the API (and the X-WSSE header), but it also supports the SOAP header mapping.
This is actually version 0.02. 0.01 was released on September 8, 2003, and used the almost-Digest authentication mechanism described here. This has been replaced in 0.02 with the WSS mechanism. 0.02 also adds preliminary namespace support.
Here's some sample usage:
use XML::Atom::API;
use XML::Atom::Entry;
my $api = XML::Atom::API->new;
$api->introspect('http://www.my-weblog.com/atom');
$api->username('Melody');
$api->password('Nelson');
my $entry = XML::Atom::Entry->new;
$entry->title('New Post');
$entry->content('Content of my post.');
my $url = $api->createEntry($entry);
XML::Atom will provide the basis for the Atom support in TypePad and Movable Type. XML::Atom is free software, and can be redistributed and/or modified under the same terms as Perl itself.
Requirements and more information can be found in the distribution.
8 Comments
So let's see: 0.01 supported Atom-digest, which allows both client and server to verify to each other that they know the user's password, but does not require either client or server to store that password in plaintext. 0.02 replaces this with WSSE, which offers no verification that the server you think you're talking to actually knows the password (and could therefore easily be spoofed), and requires both client and server to store the password in plaintext.
Why is this progress?
Mark--
I was going on what is posted at http://www.intertwingly.net/wiki/pie/DifferentlyAbledClients, and assuming that was the latest version of how clients and servers should authentication.
I agree that the storage in plaintext is a big issue, but the same issue is present for the Atom-digest authentication--the password doesn't need to be stored in plaintext, but it does need to be stored in the exact format described by the spec. And that's not going to work--we can't even write a conversion script, because the password is stored in hash format and we don't know the original.
So, I think this is a problem in both WSSE and Atom-digest. Sam seems to be somewhat cryptically indicating that there is a solution. :)
Ben
Ben,
I'm not familiar with the internals of MT, but I did notice that David Raynes had already encounted this and had posted a diff to handle the problem:
http://www.rayners.org/2003/09/11/updating_mt_to_play_well_with_atom.php
Not sure if that helps.
-joe
"Somewhat cryptically"? - NICE PUN!
Let's start with the simplest solution: provide an option to mail the user a hex digest of their hashed password for them to use as their PIN.
If it makes you feel more comfortable, do a sha1 hash of username + ":" + realm + ":" + the hext digest of their hashed password, and return a hex digest of that.
Email is just one option. A CGI which performs the existing crypt function (plus whatever you chose to add per above) would suffice.
I think we are asking more of the protocol than is necessary. Just my opinion. In the case where strong authentication is required, then shouldn't the user be using whatever protocol over SSL? Do we have to build strong authentication into every blogging tool?
Few bloggers have either the technical acumen or the hosting plan to use SSL. The consensus up until now has been that they deserve strong authentication despite their bare-bones hosting situation. There are many ways to achieve this; simply throwing up your hands and saying "just use SSL" is a cop-out.
I disagree. I use clear-text web form auth over HTTP. I think most bloggers do. In fact, so does most of the online gambling community. No fear. It's just my blog ;)
Randy, you are free to continue to use insecure authentication protocols that send cleartext passwords over the wire. The rest of us feel we would like something better.