Users and Authentication

User Profiles

The tricky part about user profiles is figuring out where to put them.

• Really sensitive information, like passwords, credit card numbers, and social security numbers goes into a database. Preferably, except for passwords, on another machine. We can ignore all but the passwords for the moment.
• Stuff the user wants to hide that isn't extremely sensitive can go into their user directory or a Private subdirectory of it, as long as it isn't web-accessible to anyone but the user. It could also go into a separate directory tree that's not web-accessible; this is largely a matter of taste.
• Stuff the user wants to make public can go into their user directory. On the other hand, we could perfectly well keep it with the rest of their profile if there's a good way to display it selectively. Or as yet another (even simpler) alternative, the user could just put it on their pages if they want it, and not otherwise.

So what we'll do for the moment will be to put the whole profile into /m//UserDir/.profile.cf, which we will make sure is not be web-accessible at all. It will be accessible, then, only via the appropriate CGI -- sites will have control over where they go, exactly. Also for the moment, we'll assume that every "user" is a member.

There's also the little matter of a possible mapping between account name and UserDir name. We won't even think about that one!

Authentication and Access Control

User authentication is tricky.

Current Thinking

It's ok to use Basic authentication on both servers provided we don't require an authorized user for access to the public parts. For that we use a cookie. And whether a user wants Basic or cookie on the file.cgi virtual DAV server is up to them; if they don't already have the cookie it will do Basic, on the assumption that they may be using a client that tosses its cookies.

Directories and files can be treated differently, because directories are listed using a CGI, which can check permissions. We can, in fact, make some directories (like /m/*) listable only by members while allowing full access to the /m//* member pages to anyone who knows where to look.

So the only thing that's tricky is giving cookie users access to their own private files and to files (not directories) with read restrictions. For this we let the "authorization required" error handler bounce them over to the corresponding path under view.cgi if all they have is a cookie.

The Old Writeup

We pretty-much have to use Basic authentication on the DAV server -- that's about the only way we can restrict access in users' directories, using Require user whoever; most (all?) DAV clients can't deal with form-based logins or cookies.

But we don't want to require Basic authentication on the main server, so the two servers have to have different names for the file that is normally called .htaccess. We can live with that. We'll use .htaccess on the main server, because that's going to be the one that everyone uses most of the time. (It would be tempting to use AllowOverride none on the DAV server, but then we'd have to have a server <Location ...> directive for every user. That way madness lies.)

So we use cookies or sessions on the main server. Probably the simplest thing in that case is to bounce them -- members, anyway -- over to the DAV server for login, then plant the appropriate cookie. A form would be more polite but wouldn't log the user in on both servers at once. If most users aren't using DAV, or use it only sporadically, that would be OK.

If a user decides to let us make the cookie permanent, they won't have to log in again unless they want to edit their pages using the DAV server, which presumably won't happen very often. Still a bit annoying, but it's hard to think of anything better.

The only other time they'd have to log in is if they want to visit a subdirectory that they themselves have protected. Which is a bit of a pain, but presumably most authors won't do that. An alternative would be to redirect them over to the corresponding directory on the edit tree, possibly using special names for private directories so that mod_rewrite can do the work. It would still require a login, of course, but it would be done on the edit tree and so would pertain to all subsequent edits in the session.

An alternative, of course, would be to write a new authentication module for Apache. Gaak! (Probably doable with mod_perl.)