[Clipart] XML hierarchies, the DMS, daemons, and Debian

[Bryce Harrington]

On Fri, 15 Oct 2004, Nathan Eady wrote:
> Bryce Harrington wrote:
> > That calls the dms on freedesktop.org and pulls down the ID numbers for
> > all the documents currently loaded there.  I've omitted the error
> > handling for brevity, but look at ls_docs in dms/scripts for the
> > complete script.
> 
> Interesting.  So basically it's an interface for (possibly remote)
> querying, then?  Looks useful.

Precisely.  An XML-based RPC mechanism.

> > *Nod* Sounds sort of similar to how Apache::AuthTicket works (which we
> > use at work), except that it issues tickets, which expire after a
> > predefined time and require re-authentication.
> 
> That's where the expiration timeframe comes in.  Either the code that
> checks the cookies can also check their expiration timeframe against
> the current time, or (more efficient) a daemon or cron job can delete
> all the expired ones every n minutes (or hours).

*Nod*  Here is what I've found for SOAP ticket-based authentication:

    http://www.perl.com/pub/a/2001/04/24/soap.html

(Scan for the 'Ticket-based authentication' section).

> > It would probably be worth looking at how Mantis does it, because it
> > probably already has this stuff implemented and we could just piggyback
> > on it.  (From my previous experience setting up the aforementioned
> > ticket system, they're a pain in the ass to debug.)
> 
> We _might_ even be able to just point users to the Mantis form for
> creating new accounts.  In any case, we want the rest of the site to
> share user accounts with Mantis if possible, right?

Yeah, that's what I'm hoping.  I'm going to play around with this daemon
auth and will see if it can be made to tie in with the Mantis system.

> > I doubt it's much of a threat, but we probably ought to do it right.
> > I agree that https for the whole site is overkill, but the login form
> > itself should be kept secure, even if only for good practice reasons.
> 
> Makes sense to me.  Account creation and login should use https; the
> rest of the site can stay on http.

Do we need to mess with certificates in order to do this?  

Bryce