[06:06:52] AaronSchulz: idk what's up with https://gerrit.wikimedia.org/r/#/c/263867/ [16:52:27] anomie: can you look at https://gerrit.wikimedia.org/r/#/c/155691/ when you have time? [16:55:59] jackmcbarn: I'll try to find the time [18:40:31] * legoktm lols at https://phabricator.wikimedia.org/T16504 [18:48:30] AaronSchulz: please don't manually submit changes and bypass CI, master is broken right now [19:04:15] hahah [19:04:48] PhpStorm 11 EAP [21:02:44] Sigh, PHP. You allow for an array to have string "1" as a key (e.g. when casting from object to array), but then you do everything wrong when trying to deal with it. [21:12:22] csteipp: this just showed up in my "new books" feed, in case you're interested: http://www.amazon.com/Secure-Your-Node-js-Web-Application/dp/1680500856 [21:12:37] no idea if it's any good [21:13:37] judging by the cover it's super good [21:13:52] all matrix up in there [21:14:12] That is an almost awesome cover [21:15:30] I'm not sure if that's the bad guy being kept out or the wizard who does it -- https://imagery.pragprog.com/products/443/kdnodesec.jpg?1433877235 [21:31:00] anomie: PHP fun fact: $a[1.5] and $a['1.5'] are not the same item [21:32:11] tgr: It rounds the first one to $a[1], doesn't it? [21:32:27] yes [21:32:47] lots of fun when you deal with numbers read from GET and such [21:33:48] anomie: bd808: do we have a timeline for auth updates to the mobile apps? I had a talk with Adam over lunch and he says they will need about two months to make a change and get it out to the stable channel [21:34:35] so if they need to do anything when AuthManager is deployed, we should probably talk to them now and tell them to at least reserve a sprint [21:34:50] tgr: Hmm. I'd better raise my internal priority on writing the action=clientlogin code so they can get started then. [21:35:55] * anomie will try to ignore email tomorrow [21:36:06] I think the worst case will be that users needing some secondary auth interaction will not be able to login via apps [21:36:30] ^ True. But that could be considered a pretty bad worst case. [21:36:34] Until we have 2factor done who might that effect? [21:36:42] in a way, that's the best case [21:37:04] I think it's basically *the* case, best and worst ;) [21:38:09] will error messages stay stable, for example? bd808 looked it up recently and at least the iOS one has it's own error message translation table [21:40:05] We don't have $wgBlockDisablesLogin set on public wikis, we don't expire passwords, and we don't have any linking providers. So maybe only if they need to reset the password if something like T119100 happens. [21:41:00] or if they run into CentralAuth rename weirdness, although I would be surprised if their current login handled that [21:41:35] Good point, error messages will get less useful. The new code for action=login will have just "Failure" or "Aborted" with a property with a 'reason' string, rather than different statuses for blocked, throttled, and so on. [21:43:53] also, maybe worth asking if there is some phone-specific login workflow that we did not think of [21:44:32] like, how does Google account login work on Android? it does not ask for your password and I don't think there is any redirection [21:46:29] Unless MobileFrontend does something crazy, I can't think of one that could exist now. The Google account thing on Android would probably have to have the extension take advantage of $response->redirectApiData somehow (that's basically what redirectApiData is for). [21:51:47] tgr: Detail: The login-with-Google extension would return a REDIRECT response that had some GoogleAuthDataAuthenticationRequest in ->neededRequests. The API would dutifully return the ->redirectTarget and ->redirectApiData. Most clients would redirect to ->redirectTarget and when it eventually comes back use the data passed to the $returnToUrl to populate the fields needed for the GoogleAuthDataAuthenticationRequest. But the Android phone could [21:51:47] instead see that it's a Google account request, extract anything needed from ->redirectApiData, do whatever internal API calls, and get the fields needed to populate the GoogleAuthDataAuthenticationRequest that way. [22:52:12] where are API continue parameters handled? [22:53:36] never mind [22:57:01] just trying to figure out ApiQueryPageProps for https://gerrit.wikimedia.org/r/#/c/263581/ [23:08:42] TimStarling: in https://github.com/facebook/hhvm/pull/5340#issuecomment-136267049 , you mention "another patch" -- is that available anywhere? Did it just get folded into PR #5340 eventually? Our package as only , which corresponds to #5340 [23:08:52] s/as only/has only/ [23:10:47] I should probably clean up the branch list in my fork... [23:10:56] it's possible it is in there somewhere [23:14:08] yeah, so here is the dev branch: https://github.com/tstarling/hiphop-php/tree/output-buffer-dev [23:14:32] my dev branches generally have commits in the order I wrote them, which I then reorder and squash for PR branches [23:15:21] so I think the top commit there was a fix to the previous work which you probably already have [23:15:41] but the second-top commit is the new work which you don't have, i.e. https://github.com/tstarling/hiphop-php/commit/52aa28fc04843c64277913946815971ed6488dbd [23:16:37] our package should only have the temporary hack, not any of these commits [23:19:09] yeah, output-streaming.patch is the temp hack, it doesn't correspond to any PR [23:19:57] what I handed over to paravoid was https://reviews.facebook.net/D51855 , which is a rebase of tstarling:output-buffer-fix-flush [23:20:06] but not output-buffer-dev [23:20:14] * ori diffs [23:20:22] yeah, which is fine, that is the work I already submitted as a PR, right? [23:20:34] oh, a diff is probably not what you want [23:21:35] https://github.com/tstarling/hiphop-php/compare/output-buffer-fix-flush...tstarling:output-buffer-dev [23:21:42] yeah [23:22:21] joelm asked me to resubmit it [23:22:47] I eventually got lazy about committing things to the dev branch and cherry picking them into the PR branch [23:22:59] well, you can hardly be blamed for that [23:23:14] so I think a number of the commits in output-buffer-fix-flush are changes requested in CR that are not in output-buffer-dev [23:23:57] I think all you really need to do is cherry pick 52aa28fc04843c [23:25:27] I'll give that a shot [23:49:42] it was easy to cherry-pick, only one hunk did not apply cleanly and it was trivial to fix.. building now