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

[Nathan Eady]

Bryce Harrington wrote:

>>I don't know anything about SOAP, so I can't comment meaninfully here.
> 
> It's pretty transparent; there isn't much you need to know from the
> clientside.  Here, try this:  (Install SOAP::Lite, then run this)
> 
[snip code]
> 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.

>>So when login.cgi (or whatever) is called with no input (i.e., no
>>query string and no POST input), it sends a blank login form, which
>>points back to the same script; when the user submits the form, the
>>login script checks the password and authenticates the user.  If the
>>username and password are a match, it creates a thirty-byte random
>>string of alphanumeric characters, which it sends to the browser in a
>>cookie; it _also_ creates a new entry in the cookies table keyed on
>>the _same_ thirty-byte string; this record will also contain the
>>user's username and possibly other info, such as IP address, an
>>expiration timeframe, and so on.
> 
> *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).

 > This way if you log in at a public terminal or something, the
 > authenticated cookie doesn't remain valid forever.

Right.  In an ideal world, public stations would drop all their cookies
at the end of the browser session (which is the way I have the ones at
GPL set up), but in practice there are many out there that do not.

[Creating user accounts]
> 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?

>>The only question left is whether the login script should be https; if
>>it's not, a man-in-the-middle attack could sniff an actual password.
>>Whether we consider that a likely enough or serious enough threat to
>>worry about is an open question.
> 
> 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.