[Clipart] XML hierarchy definitions

[Bryce Harrington]

On Fri, 1 Oct 2004, Jonadab the Unsightly One wrote:
> > 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?

Actually, I figured out a way to run it continuously using screen.  I
think the init approach would be better for the long run, but for now
this approach will do the job.  When dms is more matured I'll ask to
have it installed as a proper daemon.

The freedesktop.org system is Debian.  I don't have a debian system I
can develop on at present, but I'm sure I can scrounge one up if it
becomes necessary.

> 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.

I was planning to investigate auth for SOAP daemons a bit today but
didn't get a chance. 

But anyway, for code running on freedesktop.org (such as CGI's), if they
take care of authentication (using whatever mechanism), that solves the
problem.  dms can provide a raw service to them and just trust that
those cgi's are passing validated information.  This is handy since you
can use any auth system you're comfortable with.

The longer term issue I want to figure out, though, is direct auth to
the service from anywhere.  This would allow, for instance, one of us
admins being able to run scripts from our local machines to do bulk
operations (recategorization of a set of clipart, submission of a
collection of items, etc.) 

> 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.

Totally agree, this is the best possible case.  Storing the auth info in
a rdms would also enable the remote commandline approach mentioned above
to be able to use the same authentication.

> 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.

Yeah, that'd be cool.  I'm ok with the dms trusting the calling code,
although you're right that it's less secure.  But as long as we
configure things carefully it could work ok.  But yeah, if we could
provide a common mechanism for handling all the auth, that'd be
preferable. 

> 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.

correct

> 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.

I've actually developed such a system at OSDL when the company first
started - and it's still in regular use.

You're right that there's some packages on CPAN that do this, some
better than others.

However, I've got a plan here.  One of the things I was looking for when
I picked out mantis was its authentication system.  Having developed
auth systems before, I really didn't want to have to do it yet again.
Most bug trackers have an auth system built into them, for obvious
reasons, and I figured regardless of what we did for auth, we'd want to
tie it in with bug tracking, so users wouldn't need separate accounts
for submitting bugs from doing other stuff.

What I would suggest is this - log into freedesktop.org and browse
through the mantis source code to learn how it does the authentication.
I think the mysql account info is listed there; use that to log into
mysql and look directly at the database if you're comfortable doing
that.  Doublecheck that it produces login cookies that we can reuse (I
believe its a ticket-based system iirc.)  Then think about seeing how we
could hook into that with php and perl, so that we can add support for
it to our other tools.  In theory, if this works as I think it will, we
can just leverage off mantis and avoid having to create our own account
management stuff, etc. etc. (unless we want to, maybe later).

Bryce