[Clipart] XML hierarchy definitions

[Jonadab the Unsightly One]

Bryce Harrington <bryce at bryceharrington.com> writes:

>> Unwarnocking is when you bring a warnocked topic back up and talk
>> about it.
>
> Huh.  What's the entomology?  

Etymology you mean.  Comes from the Perl community.  I believe it's
named after some guy named Warnock who sent a post that famously got
warnocked.

> Neither google nor wikipedia recognize the word.

I must be misspelling it.  Hmmm....  Oh, "De-Warnocked" or
"un-Warnocked" turn up, and of course "warnocked".  For some reason
it's usually used in the past tense.

>> Directory structure?  I thought we wanted the various tools (browse
>> and so on) to read from the DMS directly?
>
> Correct.  For the monthly release creation tool, we need a routine
> that read from DMS directly and use the xml hierarchy to produce a
> directory structure that can be tarballed.

Oh, yes, for the releases.  That makes sense.

>> Right.  So as arguments you're going to feed it an XML heirarchy
>> (as a string most likely) and some options (in a hash probably).
>> And it's going to return...  a nested data structure whose leaf
>> nodes are handles or magic tokens that can be used to retrieve
>> files from the DMS, is that about right?
>
> That's a step in the direction, but we need to flatten to
> directories and files.

The release creation tool could call a routine that does the above and
then walk it to retrieve the files.  Using Archive::Zip, it could
probably create the release directly then.

> Yep, one of the reasons I've focused so exclusively on the dms is
> because it seems to be the keystone for making everying else work
> smoothly.

Agreed.

> As to status of the dms, I've been investigating how to set up the
> daemon to get invoked as an init.d script (with pid files and such).
> I got it solved for gentoo and am 80% through getting it to work on
> RedHat-style systems.  

Which type of system is the freedesktop.org server the site is hosted
on?

> I started investigating how to do authentication (so we can track
> which user submits stuff), but all of the examples have shown how to
> do it if you're running the server as a CGI; since I'm implementing
> this as a daemon, none of that applies so I'm still seeking
> solutions (I'd like to avoid implementing my own authentication
> system).

Okay, I'm going to think out loud here...

The DMS is going to be called by various code, most of it running in a
CGI interface (or later maybe mod_perl).  The code that calls it is
going to get auth credentials from a user _once_ and then send the
user a magic cookie, which the browser will store.  The cookie
shouldn't contain the auth credentials themselves for security
reasons, so subsequently something will look up the cookie in a
database or something to see that it's valid and which user it
represents.  The DMS could serve as the "database or something" that
everything looks up the cookie in.  Or that could be separate from the
DMS.  Not sure which approach is better there.

We'd like all the pieces of the site to use the _same_ authentication
mechanism, so that the user can log in once and use all parts of the
site.  This means both PHP and Perl code need to be able to call code
that looks up the cookie.  (However, the thing that takes auth info
from the user and sends it to the auth thingydo to _create_ the cookie
and send it back to the user can be written in one language.)  One of
the easiest ways to achieve this would be if the cookies were stored
in a relational database (e.g., MySQL), since both PHP and Perl have
good database interfaces and could easily look up the cookie there.

Since the DMS is one of the things that needs to be able to check that
the user is valid, the calling code can pass it the cookie, and it can
look up the cookie in the database for itself.  That way the DMS
doesn't have to trust the calling code -- though it does trust the
code that checks the user's credentials and creates the cookies and
stores them in the database; everything has to trust that.

This brings us down to that code, the code that examines the user's
credentials and, upon determining that they're valid, creates a cookie
to give the user, and stores the cookie in the database along with the
username of the user.  How does this code determine whether the user's
credentials are valid?

I don't think it should check based on OS-level credentials, because I
think it will be useful for people to have an account for contributing
content without having a shell account on the server.

We could store the usernames and passwords in another database table,
but then anyone with database-level access to it could read them out,
and since people tend to use the same password for multiple things, we
might ought to avoid that.  We could hash it or something, but I know
a lot less about that -- although there are modules on the CPAN that
could do the hashing for us.

This raises also the question of account creation:  do we want people
to be able to easily create accounts?  Should they have to have a
valid email address to do so, and receive a message with a key to
unlock the account?

This is the part of authentication we most need to talk about, I
think.

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/