(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)
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)