SUL caveats

List overview All Threads
Download

newer

older

hate catching up with sidebar...

MediaWiki 1.12.0 released

Tim Starling

25 Mar 2008 25 Mar '08

8:27 a.m.

Some lucky people might be able to create global accounts at the moment, but please note the following caveats: 1. Local access control on account creation is largely broken. The new user log, IP blocks on account creation, and AntiSpoof conflict checking are broken. Only private and fishbowl wikis are still protected. 2. Email address changes are local and don't propagate properly to the other wikis. 3. There's no cookie sharing so you have to log in to each wiki separately. 4. There's no shared preferences except password 5. You can't rename a global account. I intend on fixing items 1 to 3, in that order. I won't make any guarantees for 4 or 5, maybe someone else is interested in them. -- Tim Starling

Show replies by date

Aaron Schulz

25 Mar 25 Mar

8:55 a.m.

I'm interested in 5 already; I'd really like for renaming to be possible. -Aaron Schulz

...

To: wikitech-l(a)lists.wikimedia.org From: tstarling(a)wikimedia.org Date: Tue, 25 Mar 2008 17:27:33 +1100 Subject: [Wikitech-l] SUL caveats Some lucky people might be able to create global accounts at the moment, but please note the following caveats: 1. Local access control on account creation is largely broken. The new user log, IP blocks on account creation, and AntiSpoof conflict checking are broken. Only private and fishbowl wikis are still protected. 2. Email address changes are local and don't propagate properly to the other wikis. 3. There's no cookie sharing so you have to log in to each wiki separately. 4. There's no shared preferences except password 5. You can't rename a global account. I intend on fixing items 1 to 3, in that order. I won't make any guarantees for 4 or 5, maybe someone else is interested in them. -- Tim Starling _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_________________________________________________________________ In a rush? Get real-time answers with Windows Live Messenger. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refres…

Platonides

1:53 p.m.

Tim Starling wrote:

...

2. Email address changes are local and don't propagate properly to the other wikis. -- Tim Starling

Are email addresses (supposed to be) changed on ''slave accounts'' when unifying? Seems that my email has been changed to the one of the main account (checking afterwards those confirmed by password) and the timestamp of verification has been changed on all projects... except on commons, which keeps the previous email and verification date. BTW, going back and resending from Special:MergeAccount?action=submit produces a not too graceful internal error 'Already exists -- race condition'

masti

2:29 p.m.

even when you get thru this error it keeps telling me that "None of the accounts can be confirmed using this password" and at the same time I can log into those wikis with my password. And it does not let me finalize the account creation masti

...

BTW, going back and resending from Special:MergeAccount?action=submit produces a not too graceful internal error 'Already exists -- race condition'

Thomas Dalton

2:34 p.m.

On 25/03/2008, masti <mst(a)warszawa.pl.eu.org> wrote:

...

Finalising the account creation seems to happen automatically, it's just a slightly poor interface on this beta version - I'm sure it will be made more clear in time.

Tim Starling

3:41 p.m.

Platonides wrote:

...

Tim Starling wrote:

2. Email address changes are local and don't propagate properly to the other wikis. -- Tim Starling

It's updated from your global account when you go to Special:Userlogin and log in to that wiki. Obviously it should be updated when someone tries to send you an email, if not before. -- Tim Starling

Thomas Dalton

2:08 p.m.

Aren't accounts with no edits meant to be automatically usurped? If so, it doesn't seem to be working. (Unless the accounts all have deleted edits, I suppose, but that seems unlikely.)

David Gerard

2:21 p.m.

On 25/03/2008, Thomas Dalton <thomas.dalton(a)gmail.com> wrote:

...

Aren't accounts with no edits meant to be automatically usurped? If so, it doesn't seem to be working. (Unless the accounts all have deleted edits, I suppose, but that seems unlikely.)

I couldn't log into de:wp as myself as yet. So presumably all this functionality will slowly come online for all admins? - d.

Tim Starling

3:37 p.m.

David Gerard wrote:

...

On 25/03/2008, Thomas Dalton <thomas.dalton(a)gmail.com> wrote:

Aren't accounts with no edits meant to be automatically usurped? If so, it doesn't seem to be working. (Unless the accounts all have deleted edits, I suppose, but that seems unlikely.)

I couldn't log into de:wp as myself as yet. So presumably all this functionality will slowly come online for all admins?

Click the "Manage your global account" link in your preferences, or go to [[Special:MergeAccount]]. Later on, it'll pop up when you try to log in. -- Tim Starling

David Gerard

3:56 p.m.

On 25/03/2008, Tim Starling <tstarling(a)wikimedia.org> wrote:

...

David Gerard wrote:

...

> I couldn't log into de:wp as myself as yet.

...

Click the "Manage your global account" link in your preferences, or go to [[Special:MergeAccount]]. Later on, it'll pop up when you try to log in.

OK, I did this from en.wikipedia.org, and it merged the accounts from commons.wikimedia.org, cy.wikipedia.org, en.wikipedia.org, en.wikinews.org, en.wikiquote.org, www.mediawiki.org and meta.wikimedia.org - which is indeed the list of places on Wikimedia I have an account called "David Gerard". I tried logging into de.wikipedia.org (where I didn't previously have an account) as David Gerard with both the passwords I was using, neither worked. I then tried *creating* an account on de.wikipedia.org as David Gerard with the en:wp password, and got the error "Fehler bei der Anmeldung: Cannot create account: the requested username is already taken in the unified login system." (Yes, German then English.) What should in fact be happening? - d.

Tim Starling

4:07 p.m.

David Gerard wrote:

...

On 25/03/2008, Tim Starling <tstarling(a)wikimedia.org> wrote:

David Gerard wrote:

> I couldn't log into de:wp as myself as yet.

Click the "Manage your global account" link in your preferences, or go to [[Special:MergeAccount]]. Later on, it'll pop up when you try to log in.

What should be happening is that you should now be able to log in to de.wikipedia.org as "David Gerard" with the password you were using on en.wikipedia.org. The error you quoted is not localised yet because I only added it a few hours ago. -- Tim Starling

David Gerard

4:22 p.m.

On 25/03/2008, Tim Starling <tstarling(a)wikimedia.org> wrote:

...

What should be happening is that you should now be able to log in to de.wikipedia.org as "David Gerard" with the password you were using on en.wikipedia.org.

I just tried again and it worked. w00t! I also tried on sv.wikipedia.org (to pick a wiki at random) and got in there too. w00t!

...

The error you quoted is not localised yet because I only added it a few hours ago.

Fair enough :-) - d.

Finne Boonen

5:22 p.m.

I tried to unify my logins that the automatic system was sure were mine from nl.wikipedia.org and got: Interne fout Already exists -- race condition Backtrace: #0 /usr/local/apache/common-local/php-1.5/extensions/CentralAuth/SpecialMergeAccount.php(66): SpecialMergeAccount->doInitialMerge() #1 /usr/local/apache/common-local/php-1.5/includes/SpecialPage.php(461): SpecialMergeAccount->execute(NULL) #2 /usr/local/apache/common-local/php-1.5/includes/Wiki.php(227): SpecialPage::executePath(Object(Title)) #3 /usr/local/apache/common-local/php-1.5/includes/Wiki.php(55): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest)) #4 /usr/local/apache/common-local/php-1.5/index.php(92): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest)) #5 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...') #6 {main} On Tue, Mar 25, 2008 at 3:22 PM, David Gerard <dgerard(a)gmail.com> wrote:

...

On 25/03/2008, Tim Starling <tstarling(a)wikimedia.org> wrote:

What should be happening is that you should now be able to log in to de.wikipedia.org as "David Gerard" with the password you were using on en.wikipedia.org.

I just tried again and it worked. w00t! I also tried on sv.wikipedia.org (to pick a wiki at random) and got in there too. w00t!

The error you quoted is not localised yet because I only added it a few hours ago.

Fair enough :-) - d. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- "Maybe you knew early on that your track went from point A to B, but unlike you I wasn't given a map at birth!" Alyssa, "Chasing Amy"

Mohamed Magdy

5:52 p.m.

while(1){echo "Thanks";} for this great thing. I didn't have any issues.. /me waits for alnoktaBOT to be merged :) -- --alnokta

Tim Starling

3:32 p.m.

Thomas Dalton wrote:

...

Aren't accounts with no edits meant to be automatically usurped? If so, it doesn't seem to be working. (Unless the accounts all have deleted edits, I suppose, but that seems unlikely.)

That was disabled. The feature as written was insecure, it allowed a malicious user to easily hijack a global account by creating an account with no edits before it was merged. Doing it properly was looking complicated, so it's disabled for now. -- Tim Starling

Erwin

26 Mar 26 Mar

12:17 a.m.

On Wed, 2008-03-26 at 00:32 +1100, Tim Starling wrote:

...

Thomas Dalton wrote:

Aren't accounts with no edits meant to be automatically usurped?

That was disabled. (..) Doing it properly was looking complicated, so it's disabled for now.

Does that mean that you have to register and usurp those accounts locally for each wiki? How should we deal with user name conflicts? I'm asking this both as a bureaucrat and as a user who whants to usurp existing accounts. I myself have Erwin as my user name on my home wiki (nlwiki), meta, commons and some other wiki's and have the most edits of any of the accounts called Erwin. On some wiki's, including enwiki and dewiki, my user name is Erwin85 and I made edits which I want to be attributed to my planned global account Erwin.There are quite a few Wiki's where "Erwin" has no edits, but on enwiki and dewiki the user has > 100 edits. I've been told that if I merge my account called Erwin, my accounts called Erwin85 on other projects can't be renamed to Erwin. And I guess a request to usurp Erwin on those Wiki's will be denied at the moment. So how should I deal with this and how should bureaucrats deal with similar situations now and in the future? --Erwin(85)

Simetrical

2:43 a.m.

On Tue, Mar 25, 2008 at 6:17 PM, Erwin <erwin(a)wikipedia.be> wrote:

...

On Wed, 2008-03-26 at 00:32 +1100, Tim Starling wrote:

Thomas Dalton wrote:

Aren't accounts with no edits meant to be automatically usurped?

That was disabled. (..) Doing it properly was looking

complicated, so it's disabled for now.

Does that mean that you have to register and usurp those accounts locally for each wiki?

You don't have to register. In fact, doing so is entirely pointless at least after you unify your account. Get a local bureaucrat to do the rename, and once the local account is out of the way, the name is reserved for you whenever you want it.

...

How should we deal with user name conflicts? I'm asking this both as a bureaucrat and as a user who whants to usurp existing accounts.

The current best practice appears to be: * Do not unify the account if you have accounts on some wikis that aren't named the same as the primary name you'll choose. Usurp all accounts you want to usurp, *then* unify your account. * If you do get unified while you still want to usurp some accounts, you may as well get the usurpees renamed out of the way now. Bureaucrats will not be able (yet) to rename your local account to your global name. Once the way is cleared, do not log into the wiki under your unified name -- use your old account with a different name. (Logging in under your unified name will create a new local account that will later have to be discarded.) This is subject to change as things are fixed and adjusted.

Brion Vibber

25 Mar 25 Mar

6:38 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Starling wrote:

...

Some lucky people might be able to create global accounts at the moment,

Woo-hoo! One note -- when breezing through the unification form it's a bit easy to miss that you haven't actually changed anything yet after you've put in your password(s). The final action button is at the bottom, below a potentially *very* long list of wikis, and it's easy to miss the warning message at the top. Now, I did this first thing in the morning before my coffee, but I did *write* the thing in the first place so that doesn't say good things about its usability. ;) Perhaps moving the final unification button above the list would do the job.

...

1. Local access control on account creation is largely broken. The new user log, IP blocks on account creation, and AntiSpoof conflict checking are broken. Only private and fishbowl wikis are still protected. 2. Email address changes are local and don't propagate properly to the other wikis. 3. There's no cookie sharing so you have to log in to each wiki separately.

3) is going to be interesting. :)

...

4. There's no shared preferences except password

This one's tough; often it'd be convenient to have the same prefs everywhere, but sometimes it's not. Don't know the best way to satisfy everybody...

...

5. You can't rename a global account.

We'll definitely be wanting that in the long run. Need to be clear about permissions, though... What may be best for most cases is likely to allow people to rename their own accounts cleanly. The simplest, from a user and anti-vandalism point of view, would be to make it easy to link a new name to your existing account; you could then go by the new name, but retain your credentials, history, edit count etc while keeping the visible link to the old name for public tracking purposes. Something to consider, anyway. - -- brion vibber (brion @ wikimedia.org)

...PGP SIGNATURE...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfpKpUACgkQwRnhpk1wk44GvgCgiJzZ/R6ZZASdhEnO06nqtiGI WLoAoMuIl5KqBI7QBzxDIK+E/2cpS/em =ePNs -----END PGP SIGNATURE-----

David Gerard

7:03 p.m.

On 25/03/2008, Brion Vibber <brion(a)wikimedia.org> wrote:

...

Tim Starling wrote:

...

> 3. There's no cookie sharing so you have to log in to each wiki separately.

...

3) is going to be interesting. :)

Great big red anon warnings are local to each wiki. Hopefully someone can take an interest in fixing 3.

...

> 4. There's no shared preferences except password

...

This one's tough; often it'd be convenient to have the same prefs everywhere, but sometimes it's not. Don't know the best way to satisfy everybody...

Have sensible defaults. What percentage of the test population have *any* changes from the defaults? What changes do what percentage of the test bunnies tend to have? - d.

Bryan Tong Minh

7:04 p.m.

On Tue, Mar 25, 2008 at 5:38 PM, Brion Vibber <brion(a)wikimedia.org> wrote:

...

4. There's no shared preferences except password

This one's tough; often it'd be convenient to have the same prefs everywhere, but sometimes it's not. Don't know the best way to satisfy everybody...

A preference whether the preferences should be local or global. But should such a preference be local or global itself?

Simetrical

7:16 p.m.

On Tue, Mar 25, 2008 at 1:04 PM, Bryan Tong Minh <bryan.tongminh(a)gmail.com> wrote:

...

A preference whether the preferences should be local or global. But should such a preference be local or global itself?

The really granular way to do it would be a global preferences page plus local ones, with an option for each local preference: "inherit from global preferences".

Platonides

11:44 p.m.

Brion Vibber wrote:

...

5. You can't rename a global account.

It's more urgent to enable renaming *to* a global account. Everybody started today noticing they have collisions and wanting to usurp for different accounts. However, once the global account is created there's no way to merge the one with a different name as the CentralAuth renaming is not active.