(cc'ing to wikitech-l)

On Wed, 19 Mar 2003, Richard Grevers wrote:

But I would never expect the latter with other sites. However, the separation between wikis is not at all evident to the newcomer. Indeed, my first assumption was of a single user database across all wikipedia entities.

This is planned, but (surprise!) not yet implemented. It requires either that all wikis are in one database (which would require more code to deal with languages and sections separately) or talk to two databases, one local and one common.

The latter approach is already being started with some experimental code Magnus has done for the interlanguage links, so in the short term we'll probably go that way. (Once someone has time to work on it...)

While we are discussing log-ins, what is the expiry time for keeping logged in status? It seems to be rather short - only an hour or so. While I don't necessarily want to use cross-session cookies, it would be nice to stay logged in for an entire browser session. Sometimes I find that I have edited an article anonymously because my login has expired in the meantime. One option could be to default to session-long logins but to have a checkbox "this is a public computer" which would introduce a 30 or 60 minute limit.

*Side usability note: it's easy to misinterpret from the layout that the 'remember my password' checkbox applies only to creation of new accounts. This should probably be changed.*

Our whole login/cookie system is crying out for improvement. I've never messed with it much because I'm not 100% sure how it works. ;)

We partially use PHP's session management, and we also set some other cookies. I don't know what the default timeouts are. PHP session cookies are IMHO problematic, because it asks to set a cookie *the first time you touch the site*. I'm sure I'm not the only one who blocks all cookies by default unless I'm deliberately logging in to a site; and we do not gracefully handle the case where someone tries to log in with cookies disabled.

(We print a blithe "success!" message, but the next page they visit is logged back out, because the session cookie isn't passed on. PHP session stuff has some funky link munging, but a) we prevent them from being put in on most pages by using absolute URLs, and b) with our current url rewriting configuration the information would be lost in most cases. And c) putting session information into URLs is *serious* bad mojo, with great possibilities for session hijacking.)

Better would be to only set cookies at login time, and to pull a redirect in the login process so we can reload and check that the cookie stuck. (Or we could check for the cookie in javascript, but I hate relying on javascript. Someone with both cookies and javascript disabled/not available should also be able to be told that they can't log in.)

-- brion vibber (brion @ pobox.com)