brion@svn.wikimedia.org wrote:
Revision: 35451 Author: brion Date: 2008-05-27 23:46:55 +0000 (Tue, 27 May 2008)
Log Message:
Add $wgCentralAuthCreateOnView config var to control the autocreation on page view for global sessions.
It's a bit annoying at the moment; clogging logs and freaking people out as they gain accounts without realizing they're visiting various sites, such as CSS and JS pulled from shared sites.
Would strongly prefer to reduce this to active behaviors at this time (edit, login, etc).
If it "clogs logs", then fix the logs. I don't buy these hand-wavy arguments about it being "scary" or "active" or whatever.
You're introducing a concept of local account creation to the user which I'd like to hide as much as possible. This is meant to be a central account system. The idea of logging in once causing you to be logged in everywhere is a simple one from the user perspective, but has been made technically complex by the choice of architecture in CentralAuth. Because of this architecture, we need to create a local user_id for each user in order for them to appear to be logged in on a wiki. This is not necessary in other implementations.
The reason the action is logged is because creation of a local user ID has been conflated with access control and trusted user verification in the MediaWiki core. But we don't have to expose this architectural tragedy to everyone who logs in to the site, we only need to expose it to people who are blocked from account creation, and to people interested in creating blocks.
I think the user absolutely should be logged in on page view. When they have a global account, they should see their name in the header wherever they go. Their preferences, such as interface language, should be immediately respected. They'll be freaked out because it'll be so great and they won't believe we could make a login system that works so well.
-- Tim Starling
On Wed, May 28, 2008 at 1:46 AM, Tim Starling tstarling@wikimedia.org wrote:
I think the user absolutely should be logged in on page view. When they have a global account, they should see their name in the header wherever they go. Their preferences, such as interface language, should be immediately respected. They'll be freaked out because it'll be so great and they won't believe we could make a login system that works so well.
I agree with this. Global log-in means you're logged in everywhere, all the time. It's all very well to say that you'll be logged in when you try to edit, but what if the first thing I want to do when visiting the wiki is change a preference? If global interface languages aren't supported, then I may want to set my interface language right away; if they are, then I definitely want to see things in my language right away!
There's no reason to stop short of total transparency of mechanism. Users should have no reason to be concerned that our (somewhat kludgy) system requires the insertion of a database row on every wiki they visit. It should just work, just like if I log in on Google I'm logged in on Gmail and all of Google's other services.
Tim Starling wrote:
If it "clogs logs", then fix the logs. I don't buy these hand-wavy arguments about it being "scary" or "active" or whatever.
You're introducing a concept of local account creation to the user which I'd like to hide as much as possible. This is meant to be a central account system. The idea of logging in once causing you to be logged in everywhere is a simple one from the user perspective, but has been made technically complex by the choice of architecture in CentralAuth. Because of this architecture, we need to create a local user_id for each user in order for them to appear to be logged in on a wiki. This is not necessary in other implementations.
The reason the action is logged is because creation of a local user ID has been conflated with access control and trusted user verification in the MediaWiki core. But we don't have to expose this architectural tragedy to everyone who logs in to the site, we only need to expose it to people who are blocked from account creation, and to people interested in creating blocks.
I think the user absolutely should be logged in on page view. When they have a global account, they should see their name in the header wherever they go. Their preferences, such as interface language, should be immediately respected. They'll be freaked out because it'll be so great and they won't believe we could make a login system that works so well.
-- Tim Starling
On the other hand, this causes problems when a user merges his accounts when some of them have different names, and thus are not merged. For example: User:Alpha@awiki and User:A@bwiki are the same user. User:A@bwiki merges his accounts. The next time he visits awiki, User:A@awiki is created. He cannot use User:Alpha@awiki any longer if he wants to use his global account, and accounts keep created in every wiki, e.g. Meta (to which he comes to request deleting the global account). This may cause problems if he wants to rename his old account or so. This problem is not theoretical: users complained of it short after SUL was enabled.
On Thu, May 29, 2008 at 2:58 AM, Rotem Liss rotemliss@gmail.com wrote:
On the other hand, this causes problems when a user merges his accounts when some of them have different names, and thus are not merged. For example: User:Alpha@awiki and User:A@bwiki are the same user. User:A@bwiki merges his accounts. The next time he visits awiki, User:A@awiki is created. He cannot use User:Alpha@awiki any longer if he wants to use his global account, and accounts keep created in every wiki, e.g. Meta (to which he comes to request deleting the global account). This may cause problems if he wants to rename his old account or so. This problem is not theoretical: users complained of it short after SUL was enabled.
Well, that will go away once all the accounts are merged. In the meantime we can put up a warning on MergeAccount saying not to merge your accounts if you want some to be renamed first.
wikitech-l@lists.wikimedia.org