Chad wrote:

I can see the usefulness in skipping the global login for debugging or for some other freaky edge case a power user might come up with. How about as a compromise, we make the feature available through a query parameter or the API?

If nobody has a really solid use case though, I'm fine with outright removal too.

Have you read https://bugzilla.wikimedia.org/show_bug.cgi?id=19161? It seems somewhat related.

MZMcBride

Chad (2011-02-17 01:52):

On Wed, Feb 16, 2011 at 7:46 PM, Brion Vibberbrion@pobox.com wrote:

...

If there's no strong objection, I'd like to revert it. If there really is some very specific need for non-global logins (wtf?!) this should be something that individual people who really need it can *get to* with their secret wizard knowledge but not inflict on everyone else. ;)

I'm fine with reverting this out of the login UI. I imagine it's only going to cause more confusion than anything for innocent users who don't really know what they're clicking. "Log me in globally? I just want to login to Wikipedia!"

I can see the usefulness in skipping the global login for debugging or for some other freaky edge case a power user might come up with. How about as a compromise, we make the feature available through a query parameter or the API?

If nobody has a really solid use case though, I'm fine with outright removal too.

Maybe this would do: #mw-centralauth-login {display: none}

That way one can use Greasmonkey or some user CSS in a browser to show it.

Cheers, Nux.

On 02/17/2011 06:46 AM, MZMcBride wrote:

If there's a way to improve the general login workflow (AJAX, CORS, whatever), I'd like to see that implemented before this checkbox is ripped out. I'm not sure, even with dark wizard magic, how you'd easily disable global login. I suppose a Greasemonkey script might be able to auto-redirect you on login or something, but that's a nasty Mozilla dependency that only works per-computer.

We could always remove the checkbox but keep the backend code that handles it. Maybe even replace it with a hidden field and pull its value from the URL, so that one could simply go to

http://en.wikipedia.org/wiki/Special:UserLogin?wpCentralLogin=0

to log in locally only.

(In any case, the way API login is currently implemented, I don't think we can easily make this available via the API without also keeping the backend available via the web UI.)

Regarding AJAX login, I agree that it would be nice and probably something the usability folks ought to look at. I've seen several third party implementations, and even written a JS-only one myself:

http://nethackwiki.com/wiki/MediaWiki:AJAXLogin.js

MZMcBride wrote:

I actually like the feature, personally, but I agree that it's UI clutter. What annoys me about global login is that it adds a noticeable delay to logging in, twice, with generally very little benefit to the user. You have to wait for the little images to load, then you have to click to go back to whatever it is you were working on, and for most people, they logged in to a specific project because they wanted to edit that specific project. They have no intention (or even care about) editing Wikiversity or Wikisource or whatever else they're now logged in to.

The reason I set to add it was that loggin in on not-too-used sites actually short lived my long sessions. Bug 24471 [1] explains a similar problem although you have to read [2] to understand it.

I agree it's some UI clutter, but there is no way to per-user hide a pre-login option. The magic parameters are good for insiders, but aren't a proper fix either.

If there's a way to improve the general login workflow (AJAX, CORS, whatever), I'd like to see that implemented before this checkbox is ripped out. I'm not sure, even with dark wizard magic, how you'd easily disable global login. I suppose a Greasemonkey script might be able to auto-redirect you on login or something, but that's a nasty Mozilla dependency that only works per-computer.

I'd like changing the way Central Auth works, so that instead of automatically being logged in, you would need to click a link, and you would be logged with the crendentials from a central site.

This would allow to fix many issues with one shot: bug 225 (use ssl for logins), bug 14407 (some wikis aren't included), bug 19161 (the privacy issue), plug certain security holes, reduce apache hits...

The main problem here is that it means a change of behavior for our lazy users (one more click!), so we should have consensus for pushing that.

I foresee something like a javascript file fetched from the login server which would eg. change pt-login to "Login as X!". The specific options would need to be discussed. Should clicking on pt-login log you automatically if you are logged in meta, or should it show you a prefilled field first, so that you can log with an alternate username? Should the edit link be hacked to log you when you go there?

It is also possible to change the cactions in that javascript, so that it would mostly look like being logged in, while actually having been served the logged-out html. It could reload the page when you use a different skin, or uncommon preferences, but the intent is to avoid that change on the normal case. It could set the Personal tools, add a watch tab, post-load your scripts and even css. But it would be harder for admins, as they have much more actions. It doesn't seem sensible to reproduce in javascript every check for editability, or places where a rollback link could be added.

The users may be happy with a limited logged-like interface though. I think they are the biggest resistance problem after they they have been given a "you are logged everywhere" system. The most affected users would be those doing cross-wiki work on very different sites: mainly global sysops and stewards. As people doing work on several wikis will keep their logins (and we can keep per-domain logins, too) maybe the impact is not so big, but I prefer not to subestimate it.

Those are a few ideas of what we could draw there. Do you like these ideas? A way to improve it? Would that completely break usability? Please share!

1- https://bugzilla.wikimedia.org/show_bug.cgi?id=24471 2- https://bugzilla.wikimedia.org/show_bug.cgi?id=14407#c30

Erik Moeller wrote:

The experience that Sage describes in bug 24471 of not being consistently logged in arguably shouldn't occur in the first place per 1). Can we log the user into _all_ public Wikimedia wikis without incurring an unacceptable performance penalty? If so, how?

We can do it if not caring about security. Which is unacceptable. So basically, I don't think we can make a magic login-everywhere, without a perfomance penalty to the servers and/or user.

The issue with regard to privacy disclosures through account creation logs is one that we should try to fix for the user per 2) and 3) without the user needing to worry about it. All the same links should be there, you shouldn't have to confirm anything when you edit a page, etc. And you certainly shouldn't have to explicitly create an account with an additional one-click operation.

Not just create an account, also logging in on eg. wikibooks when you were previously just logged into wikipedias.

It may require, per one of Brion's suggestions, to have some kind of shadow account system in the backend that's used until/unless a fully created user account is required, or to flag the account in a certain way.

CentralAuth already reserves the username, such magic adding global usernames should be possible (eg. to block a user which hasn't attached a local account yet).

Finally, I completely concur with Brion that the additional "Log in globally" checkbox should be removed, and a better solution be sought, per 1). It's not something that users should need to think about.

I'm happy with removing it *after* we get the better solution.

On Thu, Feb 17, 2011 at 3:27 PM, Platonides Platonides@gmail.com wrote:

The reason I set to add it was that loggin in on not-too-used sites actually short lived my long sessions. Bug 24471 [1] explains a similar problem although you have to read [2] to understand it.

I agree it's some UI clutter, but there is no way to per-user hide a pre-login option. The magic parameters are good for insiders, but aren't a proper fix either.

This seems like less of a per-user issue than a per-*site* issue where the affected sites are those few that are tied into CentralAuth, but don't get global session cookies...

I'd like changing the way Central Auth works, so that instead of

automatically being logged in, you would need to click a link, and you would be logged with the crendentials from a central site.

That would be a big pain in nearly all circumstances for nearly all users, so I don't think it has much chance of success as a general change to make.

I'd recommend concentrating on what can be done to make the minority case (people logging into the sites that currently don't get global cookies) look and act more like the majority case (people logging into Wikipedia and most other projects) without damaging the general case.

Good areas to explore include: * eliminating the problem of *.wikimedia.org subdomains having to be set separately by ensuring there's nothing unsafe on *.wikimedia.org * finding a way to set the cookies on all domains more quickly * finding a way to set the cookies in only one place, but be able to check them directly from all domains (not sure this is possible) * finding a way to set the cookies in only one place, but be able to check them indirectly from all domains in a way that doesn't interfere much with user activity (eg checking login state from JavaScript at start of page load, then fixing up the local session in an automatic refresh)

As a worst-case scenario, having the second-tier domains require a click in to the global login state without the inconsistencies wouldn't be too awful, but should only apply to those domains.

-- brion

Roan Kattouw wrote:

This is possible with CORS, and I suggested it a while back, see https://bugzilla.wikimedia.org/show_bug.cgi?id=20251#c8 . According to Wikipedia the latest version of every major browser supports CORS, except Opera and IE; IE has a barely usable proprietary interface to CORS in XDomainRequest, which we may or may not be able to use for this.

Roan Kattouw (Catrope)

CORS does seem to be the way to go. I have drafted a new proposal below which attempts to fix several bug in our way of doing central login.

----

Create a multilingual wiki for handling logins, available as https://login.wikimedia.org/ https://login.wikipedia.org/ https://login.wikiversity.org/ etc.

On clicking pt-login at http://xx.yyy.org you would be sent to https://login.yyy.org/wiki/Special:Userlogin (with proper uselang and full url returnto parameters)

If it is a user SULed there with the right password It performs a number of CORS POST requests[1] to each https://login.yyy.org with yyy all the upper domain levels, which set full or partial login cookies depending on the doman trust. If the source wiki is on a lower trust domain it is target of an additional login. As a last login step, it resets the continue link, which would otherwise login you through a series of redirects.

else if it is a valid local unattached account The password is verified by impersonating the source wiki. The CORS steps above are done with just the source wiki as target.

Visiting a page with full login cookies would log you in, autocreating the account, etc. (no changes)

Visiting a page with partial login cookies (and no logout) would remove the cookie, replace the visited page with a lightweight page (We are processing your login) which connect using CORS to https://login.<project>.org setting your credentials and reloads to the full page [2]. There's a redirect-driven fallback.

*************************************************** What are you naming full and partial login cookies? A full login cookie is one that automatically logs you in. Those would be centralauth_Token and centralauth_User, used as we currently do. A partial login cookie is one that sets just centralauth_User (and unsets the logged out one) so that it doesn't allow credential thief [3]. The loginwiki still sets a httpsonly cookie for itself in such case.

What kind of content would you put on that wiki? None. That's not a wiki designed to be edited. We could allow editing the login messages using its MediaWiki namespace or force everything to go through translatewiki. It would use its local load.php to avoid mixed content warnings. It can be later reused for other purposes, such as managing global preferences, though.

We would need to change all our infrastructure to support https wikis! All requests will be uncacheable [4], it doesn't need a squid/varnish in front of it. I would begin by placing a single server with multiple interfaces and slowly moving the wikis to use it.

Why use it with several domains? That way, it can securely set cookies for the source wiki even if the browser doesn't support CORS [5]. It is also more consistent than delegating on one wiki for setting the subdomain cookies.

The users shouldn't be taken out of their wiki By keeping the project domain, they are unlikely to feel that they are sent to a completely different site. The skin look and feel will be the same as the wiki from which they come. The only difference would be the sidebar, which we can fetch from the source wiki, or replace with password related topics.

Which CORS policy does it need? The proposed can work securely by relying just in cookies and queries, so it would work with even a * Access-Control-Allow-Origin. It's probably safer to set it to *.wikipedia.org, *.wikimedia.org etc.

Can JSONP be used instead of CORS? All of the above protocol could be performed with JSONP, but then it would be vulnerable.

1 - Using simple POST requests does not need preflight queries. 2 - It would be possible to add an iframe fallback for older browsers. 3 - It can also be a completely different boolean cookie if matching username with the ip is a concern. 4 - Except CSS/JS ones. 5 - That means a redirect return for domains with partial logins.

On Sun, Feb 20, 2011 at 1:20 AM, Platonides Platonides@gmail.com wrote:

Create a multilingual wiki for handling logins, available as https://login.wikimedia.org/ https://login.wikipedia.org/ https://login.wikiversity.org/ etc.

I would recommend users.*, that way in the future when we have decent interwiki trunslucation we have somewhere to stick user pages etc, as well providing somewhere sensible for global user preferences as well.

Platonides wrote:

CORS does seem to be the way to go. I have drafted a new proposal below which attempts to fix several bug in our way of doing central login.

Two questions and a comment about this.

First, would this impede the ability to switch to an AJAX login interface in the future? LiquidThreads development is working toward this goal.[1]

Second, would this impede the ability to remove the "you've been logged in" screen? Aryeh mentioned an idea that would allow MediaWiki to remove this horrible workflow interrupter.[2]

Lastly, due to the large nature of this project, the fact that it involves both sysadmins and developers, and the fact that there are high-level principles[3] that need to be kept in mind (as well as the need to track a variety of bugs and mailing list posts), I'd strongly recommend creating a "Requests for comment" subpage for this.[4]

MZMcBride

[1] http://www.mediawiki.org/wiki/File:LQT-v2-Editor-LoginPrompt-Login.png [2] http://mail.wikimedia.org/pipermail/wikitech-l/2011-February/051946.html [3] http://mail.wikimedia.org/pipermail/wikitech-l/2011-February/051939.html [4] http://www.mediawiki.org/wiki/Requests_for_comment

MZMcBride wrote:

Platonides wrote:

...

CORS does seem to be the way to go. I have drafted a new proposal below which attempts to fix several bug in our way of doing central login.

Two questions and a comment about this.

First, would this impede the ability to switch to an AJAX login interface in the future? LiquidThreads development is working toward this goal.[1]

That's interesting. There should be some synchronization so that CentralAuth could hook there, too.

Second, would this impede the ability to remove the "you've been logged in" screen? Aryeh mentioned an idea that would allow MediaWiki to remove this horrible workflow interrupter.[2]

You may have noticed that I included a horrible page to log you in instead of the content (the "lightweight page"). That can be replaced with a javascript login, if it is clear how to do it. Showing a login dialog and setting your cookies is easy. But what do you do with the previous screen? You can return to it, but oh, you have several more tabs, and it needs rollback links with tokens everywhere, and there's now a need to highlight the links to pages smaller than 500 bytes, and replacing png equations with TeX. Plus you have a couple of gadgets which needs loading, and the site javascript, which already fired would have needed to do something different. Using a separate page avoids skips that trouble. The LQTv2 you mention will have that problem, too. Unless they join the you are logged in action with the comment submit, or so.

Lastly, due to the large nature of this project, the fact that it involves both sysadmins and developers, and the fact that there are high-level principles[3] that need to be kept in mind (as well as the need to track a variety of bugs and mailing list posts), I'd strongly recommend creating a "Requests for comment" subpage for this.[4]

MZMcBride

I don't expect anyone to read it there, but may be a good idea to summarise this discussion on a page.

On 2/20/11 4:52 PM, Platonides wrote:

You may have noticed that I included a horrible page to log you in instead of the content (the "lightweight page"). That can be replaced with a javascript login, if it is clear how to do it.

That's a terrible idea. I routinely edit (and do everything else) without javascript running. There's really no need for it.

On Thu, Mar 3, 2011 at 2:37 PM, William Allen Simpson william.allen.simpson@gmail.com wrote:

That's a terrible idea.  I routinely edit (and do everything else) without javascript running.  There's really no need for it.

With JavaScript, we could skip the interstitial page when you log in and return you directly to where you were. That's useful. It would be nice if we still allowed one login for all sites for users without JavaScript, though, yeah.

Aryeh Gregor wrote:

On Wed, Feb 16, 2011 at 11:46 PM, MZMcBride z@mzmcbride.com wrote:

...

If there's a way to improve the general login workflow (AJAX, CORS, whatever), I'd like to see that implemented before this checkbox is ripped out.

Doesn't seem hard. Why don't we set an extra cookie when you log in, let's say "globalLoginRequired". Then the JS on every page should check for that cookie, and if it's present, send some background requests to log you in on the other sites. To allow for browsers that don't support CORS, we can still do image loads as now. Stick them unobtrusively in the footer, or make them display: none. Once the images have all loaded, clear the globalLoginRequired cookie.

I went to file a bug about killing the login screen with CentralAuth, but it looks like a bug was already filed a few years ago: https://bugzilla.wikimedia.org/show_bug.cgi?id=15911 ("Successful login message should not be displayed when using CentralAuth").

MZMcBride