[02:01:46] <Krinkle>	 tgr|away: could use your input on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OAuth/+/962131
[03:34:53] <tgr>	 apergos: vagrant uses <dbname>.wiki.local.wmftest.net. The right setup depends on what you want to test. Separate domains are definitely a good idea. For CA shared cookies, you'll need domains with a common component.
[03:35:56] <tgr>	 To test certain kinds of anti-tracking browser features, you need domains with no common component (a different registrable domain: https://developer.mozilla.org/en-US/docs/Glossary/Site )
[03:36:19] <tgr>	 so, it depends.
[03:37:42] <tgr>	 there are four stages of login:
[03:38:27] <tgr>	 - cookie on the parent domain (need to set $wgCentralAuthCookieDomain), ie. log in into entire wiki families instead of single wikis
[03:39:07] <tgr>	 - log in to login.wikimedia.org via a redirect chain during normal login (need to set $wgCentralAuthLoginWiki to a wiki ID)
[03:39:57] <tgr>	 - edge login (mostly at the end of normal login, but a bunch of other things can also trigger it): log in into a set of wikis ($wgCentralAuthAutoLoginWikis) in the background
[03:40:37] <tgr>	 - autologin: when you visit a wiki and aren't logged in, try to log in in the background (this is when you get a notice to reload a page)
[03:41:50] <tgr>	 the four and halfth step is trying a more aggressive version of autologin when you visit the login page
[03:43:06] <tgr>	 the shared cookie thing is done by the session provider. Logging into the central wiki is done via Special:CentralLogin. Edge login and autologin are done via Special:CentralAutoLogin (type=1x1, type=script and type=redirect, respectively) and they rely on being logged in on the login wiki.
[03:46:03] <tgr>	 On Wikimedia, shared cookies, logging into the central wiki, and top-level autologin (the aggressive version, with type=redirect) should work in all browsers (except maybe Safari which has some ill-documented rules). Autologin only works in Chrome and non-incognito Edge/Opera (assuming default settings). Edge login was fully broken, should be fixed by this week's train (T347889).
[03:46:03] <stashbot>	 T347889: Investigate why CentralAuth edge login fails in browsers that do not block third-party cookies - https://phabricator.wikimedia.org/T347889
[03:48:56] <tgr>	 re: update.php, until very recently it could only create tables in the main DB. For cross-wiki extensions that would mean a separate table for each wiki, which means the extensions kind of looks like it is working but the cross-wiki functionality isn't actually cross-wiki.
[03:50:21] <tgr>	 So many extensions including CentralAuth opted to not use update.php at all, so the breakage is more obvious and easier to debug. (There are tasks in our inbox to fix these now that core supports non-main DBs. Although I think update.php still needs to be fixed.) 
[03:50:50] <tgr>	 Not using update.php led to people sometimes being lax with documenting schema changes at all.
[04:51:32] <apergos>	 tgr:  yes, the wgCentralAuthCookieDomain was in my previous incarnation of testing "localhost" but I was getting session cookies for multiple wikis set at a singe login, and that's not right. that's what prompted me to switch to my current configuration, where "wikipedia.dev" (well now, "wikipedia.test") is the common domain and the hostnames vary on the first part of the name, much as in production. 
[04:53:16] <apergos>	 but I still have the impression that at some previous time which was still SUL time but perhaps not CentralAuth as it stands now, a single login on a wiki with attached account would trigger autologin on other project wikis, not just those in the same family. maybe I'll try digging around a little at some point and see if I can find traces of that. but not right now
[04:57:42] <apergos>	 I'm unsure of what you mean by "edge login" here, I'm used to "edge" meaning our lvs servers, perhaps you can clarify a little 
[05:01:48] <apergos>	 I do have a central login wiki in my setup, and had in the previous configuration as well, so that's not an issue btw.
[05:14:52] <apergos>	 now in looking at the linked task (sory if I'm a little slow, I am doing this first thing in the morning because I always check my irc noices first thing), it seems that the cross project autologin is the expected behaviour and that it has simply been broken for a bit. (in firefox though? huh. maybe due to my third party cookie settings.) I don't particularly understand how you got from https://phabricator.wikimedia.org/T347889#9
[05:14:53] <apergos>	 233353 to the next comment with the patch in it...
[05:15:53] <apergos>	 but that too is for later. I'll continue with my mornning routine and come back to things later this morning.
[07:31:21] <tgr>	 apergos: edge login is embedding invisible pixels in the page, which link to other wikiprojects and log you in there. Not sure why it's called that. It's controlled by the CentralAuthDoEdgeLogin session flag, mostly. 
[07:31:44] <apergos>	 ok, I'll keep in mind that usage, thanks!
[07:31:56] <tgr>	 No idea about 
[07:32:15] <tgr>	 ... https://phabricator.wikimedia.org/T347889#9233353 , it seemed to be a red herring
[07:32:48] <apergos>	 when you have time (it's late for you now, no?) I would love to hear how you got to the point of the patch, understanding that this was the likely fix
[07:32:58] <tgr>	 in the end I just read through the code for the setCookies step of edge login and spotted that the calls are in the wrong order
[07:33:48] <apergos>	 welp that's plain enough, if not something I can emulate (yet).  thanks!
[07:34:23] <tgr>	 I knew that I was looking for some cause that makes the code fail to output cookies, updating the session was definitely happening on all code paths so doing it after headers are already sent was a reasonable guess
[07:34:58] <tgr>	 I have still no clue why it didn't get logged, PHP sends warnings when you try to set cookies after the headers are sent
[07:35:21] <tgr>	 maybe worth looking into later
[07:35:39] <tgr>	 but with that patch, the cookies appeared locally, so it was easy to confirm
[07:35:43] <apergos>	 hm yes I've seen those warnings. curious
[07:37:08] <apergos>	 to test that I'm going to need a few more wikis in a different "project" but that's ok, it's about learning all the nitty-gritty after all
[07:38:38] <tgr>	 Third party cookie blocking probably also breaks edge login, independently of this bug. It depends on what domain names you use, usually browsers look at the shortest domain postfix that's not for common use (like wikipedia.org or wikipedia.co.uk). If the cross-domain calls stay within that, there is likely no blocking.
[07:39:38] <apergos>	 well I've got it turned on in firefox, so the testing should be interesting.
[07:39:45] <tgr>	 Not sure about Firefox but in Chrome these days you get pretty nice debugging tools, it gives you the list of blocked cookies, tags requests which have blocked cookies etc
[07:40:55] <apergos>	 I'm unsure about checking blocked cookies in ff, will have to look. 
[07:42:17] <tgr>	 I'll finish for today but let me know if you have any question and I'll follow up in the morning. I'll improve the docs a bit tomorrow.
[07:43:24] <apergos>	 no worries.  I need to go off and play/dig around for today, that should shed more light on things, together with the comments you've already given.  I'll write up that 'how I set things up/what not to do' doc and the end of the day.
[07:43:37] <apergos>	 *at the end
[17:36:39] <apergos>	 tgr|away:  reporting in. no writeup yet because there's still something fishy going on. I've sorted out the too-many-session-cookies so that's better, and I do see auto logins to the specified wiki in uh wgCentralAuthAutoLoginWikis so that's ok. but the so-called 'edge login' url gives a 302 to itself, so something's still off. that doesn't impact me yet because...
[17:37:03] <apergos>	 I'm only testing on one wiki family locally. but as soon as I would try to go somewhere else, I suppose there'd be a problem.
[17:39:08] <apergos>	 while looking at the html and so on,I realized another issue I have, which is rather more serious: I have no idea how the resource loader stuff works. at all. so while I can look at the code in centralauth that claims to generate an html form, I'm missing info about a bunch of pieces :-D  
[17:40:25] <apergos>	 rather than have you explain all that to me, if there's a simple walkthrough you can point me at, that would be lovely. I don't need to deeep dive any of that stuff now, just need to be able to navigate around in it a little bit, so I can see where this redirecting url comes from as far as the html retrieved by the browser.
[17:41:31] <apergos>	 thanks in advance, no rush, I have other ways to soop around in the code of course, but that knowledge seems pretty basic for any mw dev, and I'm missing it :-D
[17:55:33] <apergos>	 going to take a break now to cook and eat (9 pm here already) but will look in from time to time.
[17:56:13] <tgr>	 ResourceLoader is a big topic, and there's a bunch of documentation for it in https://www.mediawiki.org/wiki/ResourceLoader and subpages
[17:57:53] <tgr>	 it doesn't interact much with CentralAuth, there is an autologin.js file which ResourceLoader loads on every page and it triggers autologin when appropriate, there is another JS file which clears some cookies and that's about it
[17:59:16] <tgr>	 the very high level idea is that you define bundles of scripts/assets in extension.json, and then load those together either from the PHP side with OutputPage::addModule() and similar, or the JS side with mw.loader.using() and similar
[18:00:06] <tgr>	 with automatic minimizing of files, dependency resolution, selecting the right files in the case of skin-specific assets etc.
[18:00:15] <tgr>	 apergos: ^
[18:01:44] <tgr>	 basically everything related to ResourceLoader will happen via load.php URLs (plus a few <script> tags in the main document to set up the whole thing) so if the problematic URL is not load.php then it isn't RL-related
[18:02:06] <apergos>	 I know there's pilesof docs, I was hoping for some one doc that might be a gentle introduction in case I don't want to learn all there is to know :-D  
[18:03:24] <tgr>	 https://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader is reasonably gentle
[18:03:53] <apergos>	 ty!  I will have a look after getting some food into my system :-)
[18:04:29] <tgr>	 re: the 302, I think CentralAuth just doesn't handle it well when the current wiki is present in $wgCentralAuthAutoLoginWikis? production config has some logic to avoid that
[18:05:08] <tgr>	 we should probably fix that at some point
[18:06:25] <apergos>	 mm the central wiki isn't in the list. the wiki I'm tring to log into is not the hm target wiki (I have an entry "*.wikipedia.test" pointing to metawiki, and I'm not trying to log in there but to another one in the family.  but you mgiht mean something else
[18:06:37] <apergos>	 well that's what this initial learning period is for in part, figuring all that out.
[18:07:50] <tgr>	 which step do you get a 302 for?
[18:08:42] <apergos>	 the last step, going to the central wiki where an 'edge' login is supposed to happen (1x1 pixel etc) for the cross domain cookie
[18:10:10] <tgr>	 so Special:CentralAutoLogin/validateSession ?
[18:10:22] <apergos>	 no
[18:10:54] <apergos>	 http://login.wikipedia.test/mw/index.php?title=Special:CentralAutoLogin/start&title=Special:CentralAutoLogin/start&type=1x1&from=testenwiki      
[18:11:37] <tgr>	 hm. /start should not be happening on the login wiki.
[18:12:03] <apergos>	 it likely means I have something (still) misconfigured
[18:12:25] <tgr>	 there is a bit of a documentation of what all these do and where they run in SpecialCentralAutoLogin.php next to the case '<subpage>': lines
[18:12:33] <apergos>	 but I won't know what it is until I poke around some more.  (Scrying through the docs was not helpful yet)
[18:12:51] <apergos>	 I'll check those
[18:12:58] <apergos>	 probably tomorrow to be very honest
[18:13:53] <apergos>	 I did find the two methods that construct such a url, one being the domain login and one being the edge login
[18:14:17] <apergos>	 anyways, the timer just went off to tell me my pasta is ready! so I'm going to go get it :-)
[18:15:05] <tgr>	 In theory, /start is called on every wiki listed in $wgCentralAuthAutoLoginWikis. So you get a bunch of images in your page footer with src attributes like http://en.first-wgCentralAuthAutoLoginWikis-wiki.test/mw/index.php?title=Special:CentralAutoLogin/start&type=1x1&from=currentwiki
[18:16:53] <tgr>	 or maybe /start is called on the current wiki? I don't remember
[18:17:33] <tgr>	 it's a somewhat useless step, it doesn't really do anything that couldn't be omitted
[18:17:51] <tgr>	 I think it was more useful in the past when there was no central login wiki
[18:18:45] <apergos>	 once I understand well how it works (or doesn't) now, I'll be in a better position to have an opinion on what could be improved. not yet though :-D