Talk:Single login

Initial conversation

I've rewritten this page as a merger of the two pages on the same topic (now at Single login/Kowey (talk) and Single login/JamesDay and JeLuF (talk), named after their respective principle authors), and hopefully given it more structure and a more comprehensive outlook in the process. Your comments on this are of course, welcome. - IMSoP 16:02, 25 Sep 2004 (UTC)

Looking good. Hopefully this will keep the discussion from fracturing. My only comments would be that maybe a feasability study (some simple scripts on the user dbs) will help us to evaluate our options. Would be lovely if we could get the number of 1) safe automigrations 2) migration conflicts across the wikimediaverse -- Kowey 18:06, 26 Sep 2004 (UTC)

Noted. Personally, I think this is the next thing that needs doing, since only by analysing this can we make more than guesses as to how well different strategies would work. Of course, it can't tell us about how many of the non-auto-migratable names are genuine conflicts, but it would be a good start. - IMSoP 14:57, 27 Sep 2004 (UTC)

---

Alright, since JamesDay believes that there needs to be two seperate discussions for end-user and technical stuff, I have moved your synthesis to Single login/IMSoP2 (hmm... maybe that should be renamed). I'll leave it to you, IMSoP to figure out what bits of that text need to be moved elsewhere, i.e., back to single login, to single signon transition or to some other historical page. Sorry for the mess, just trying to help! -- Kowey 19:50, 21 Oct 2004 (UTC)

---

We want to setup a new wiki with two (and probably more later) different languages and a single login infrastructure. Hence, we do not have any transition problems. We plan to use subdomains like en.wikipedia.org, de.wikipedia.org. Can someone point me out where I can find information about this?

(This page should have summaries or something? I don't understand the way any of this discussion is arranged.) - Omegatron 03:40, 22 Mar 2005 (UTC)

I agree with you that the organisation of these pages is a mess. User:IMSoP and I tried to merge them all into one page, but JamesDay did not seem to agree and separated them again, probably for good reason. I have now made a new attempt to tidy things up, this time keeping Single login for summaries (like you suggest) and using Single signon transition for the gory details. -- Kowey 12:13, 24 Mar 2005 (UTC)

Ah. Now it is better. - Omegatron 19:34, 24 Mar 2005 (UTC)

A different proposal

By Omegatron: moved to Single login/Omegatron

Cheering you on

I don't fully understand the technical details, but I'm on the sidelines cheering you on. 61.59.150.192 15:45, 22 July 2005 (UTC)

Timeline

Is there a timeline for this project? -- Rachel 20:56, 15 August 2005 (UTC)

At a wikimeeeting I understood it woud be affected in february 2006, but i ahvent been able to find any confirmation. TeunSpaans 06:08, 13 January 2006 (UTC)

OpenID?

How about using OpenID (specs) for identification, i.e. all user accounts on all different wikis are assosiated with one OpenID. Let me know what you think of this idea, and, if it sounds good to you, I might be able to developer it further with help from others. --Dionyziz 10:02, 15 October 2005 (UTC)

That sounds like a very interesting idea, especially because we'd be able to generalise it beyond Wikimedia projects (there's a bunch of other wiki's i'd like to be use my sign-in for beyond the wikimedia sphere). Please do suggest a migration strategy though (or validate the prior discussions) -- Kowey 12:13, 16 October 2005 (UTC)

It wouldn't require much of a migration strategy at all. Make MediaWiki an OpenID consumer AND server, and allow OpenID accounts to have their own sets of preferences just like regular accounts. You can add as much as you want on and around this basic functionality, but it would not require ANY other junk to be done. Of course, there's some junk that would be nice in various ways. But I reckon OpenID alone is a good enough single-login solution for the vast majority of users. 75th Trombone 03:54, 22 January 2006 (UTC)

When it is good enough for the vast majority of users, it is not good enough for many. Yes it would make sense to support OpenID on one level, but we will need stronger authentication as well within the Wikimedia itself. Thinking that it does not require a migration strategy at all is wrong. There is a need for functionality on the Wikimedia Foundation level. With a single profile you DO know who your talking to as it is obvious at all times who is who. GerardM 08:14, 22 January 2006 (UTC)

Localisation

I think single Login is a good stuff. But when a User is contributing in different Languages, he/she also might want to present himself in different Languages.
Therefore we need localised User-Pages, even when the Username is keept the same in all Wikis.
MovGP0 20:40, 12 November 2005 (UTC)

Absolutely; none of the ideas that I've seen, certainly, would have the user-pages shared between different wikis, though, so I think that this is all right.

James F. (talk) 13:26, 13 November 2005 (UTC)

There will be some user preferences that will be applicable on all levels. The BABAL language information particularly is of importance in all projects. This is not to say that a user will not have its own talk page. GerardM 08:24, 22 January 2006 (UTC)

May I expect that blocking and other sysop proviliges remain local? I mean: sysops remain elected per language, and have no authority over other wikis? Some (probably small) wikis might welcome add from outside, but others will not appreciate when others start to 'interfere'. And also the other way around: As a sysop I rarely block ip-addresses or registered users, but when i do, i dont want to do that world wide. We once had a visitor from the german wiki, who was a well established volunteer there, but who started posting stuff on the dutch wiki. After repeated warnings he got a temporary block, but he remained able to work on the german wiki, and thats how it should be. TeunSpaans 06:07, 13 January 2006 (UTC)

When we find that vandalism is particularly troublesome from a particular IP-range, it will lead to different requirements for that IP-range. This will be implemented on a Foundation wide level. There are vandals who take a delight in serial offending (willieonwheels ..) on many projects. People like him NEED to be banned on a foundation level.

When an established volunteer gets banned. He/she does not know really how the system works.. Now most blocks are temporary, when such a user gets a block for upto a day, I would think that it would make him reapraise what can be done in wiki projects. GerardM 08:24, 22 January 2006 (UTC)

Looking beyond single login

Single login is a feature that would be extremely nice to have. The authentication that we need at this time is weak; the only thing that we are interested at this time in for our users is that they know a password or have a cookie. This is a very minimal specification. There are scenario's where we will have more requirements:

• When a range of IP numbers is blocked because of frequent vandalism, we want to allow access for authenticated editors. These can be schools or proxies.
• When we host educational content, we want to ensure that it is only the student who accesses his material
• When we host educational content, we want to give access to a subset of data to a teacher of a student
• When we collaborate with another web services like Kennisnet, we allow users authenticated by such an organisation to use our resources as an authenticated editor

As we are about to implement a single login scheme, I would like us to do some "future proofing". When we have the potential to do this and make use of proven open source technology, we should consider this as an option in stead of "rolling our own". A-Select http://a-select.surfnet.nl/ is a project run by "Surfnet", it is available under a BSD license. Scalability has been very much part of their existing projects. It is used as the engine for many big projects; DigiD http://www.digid.nl/ is a project to give people living in the Netherlands access to their personal information. Strong authentication like used by banks for on-line transactions are provided for. The Dutch library system, Dutch education .. they use it.

As A-Select uses open standards like SAML and as it allows for the use of many authentication technologies, it allows us to have multiple layers of security. We can make use of the authentication of other organisations where it makes sense (eg knowing that a studen and a teacher belong to the same institution). One other thing that is positive is that the people of Surfnet and Kennisnet are likely to help us if need be. For them, an implementation of a big site like ours is a great way to show again that it indeed scales well.

SSL Certificates

knowing that wikimedia trusts the CAcert certification authority i suggest using their certificates for single logons.
proof: https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page

there will be no big transition since the username + password logon still exists, however by coupling your certificate with your username on each wiki the login can become automated.

one wikimedia server keeps track of each credentials + certificate-id and eventually certificate-id + loginstatus

Has this been implemented?

I'm looking for a solution to this. Has it been implemented and if so, how would I take advantage of it? --Vcarless 02:00, 10 November 2006 (UTC)

Harhar

Single login - the Running Gag of Wikipedia... - is there something else since so much time short before initiation? Kenwilliams 13:34, 19 December 2006 (UTC)

How was this implemented

I'm a little disturbed that this was implemented at all without consideration to issues of characters in usernames. There are a host of issues which could conceivably make this a bad idea (e.g., on certain Wikipedia's the only thing we see for users is boxes). There's an ongoing discussion on the English Wikipedia of why this is a truly bad idea. The most recent example is here. Patstuart 17:14, 20 December 2006 (UTC)

Inexistent Personal Page on other Wiki

Problem: if I look at my personal page here, it is nonexistent. I think of a solution where as long as a global account exists, but not a specific user-page on a sepaarate wiki, that at leaste there is a (automatically generated) remark with the info that this is a global name - and a link to the user-page of the main wiki of that user - or even better would be to implement a unified user-page that in all wikis would be the main one. I pseudo-solved it so far that I tell on other wikis (where I did so far) to visit my user-page on my "home-wiki" - with a link to it.--ProloSozz 13:43, 3 May 2011 (UTC)

Merging with fixed IP-Addresses

I have here fixed IP-address that has changed once in the last years. So all edits done by that IP were done by me. It would be nice to make it possible "merge" IP addresses with a global account - but of course where it is clear that the IPs "belong" to a certain account. Needs for such a merge: - IP-number must be of a range that provider can confirm that not distributed dynamically, but only one user did use it. - IP-number of the user-name usese mostly that IP - no other user uses that IP Would be nice if ... please discuss. --ProloSozz 13:43, 3 May 2011 (UTC)

Layout bound to user

On my "home wiki", I use classical layout. This switches as soon as I log in; in any other wiki, I have to set that manually. It would be a great thing if the layout-type of home-wiki would also be valid for the other wikis - i.e.: if you log in any other wiki that it would automatically switch to your personally chosen layout of your home-wiki. --ProloSozz 13:47, 3 May 2011 (UTC)

Well this won't be much to do, Even if it just a message asking if you want the theme off wikipedia or the actual wiki's theme --Superlightoftruth 18:49, 17 June 2011 (UTC)