[05:55:55] anybody knows if there's any cache in mediawiki for page id -> title? LinkCache does the opposite direction... [11:15:07] duesen: do you have time to glance at https://gerrit.wikimedia.org/r/c/mediawiki/libs/ObjectFactory/+/516523 ? I'd like to merge it but since you are leading the DI project I figured you should have a chance to look at it first [11:17:33] SMalyshev: if there is, it isn't very effective - Title::newFromID doesn't use any cache [11:20:52] tgr: looks good [11:21:30] tgr: i have an UBN fix that nees review. 1 line of code [11:21:30] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/522401 [11:21:35] would you have a look? [11:21:55] ah, i should probably add instructions for testing to the commit message [11:21:58] will do that in a minute [11:25:03] nitpick: it's called RedirectSpecialPage [11:26:50] tgr: fixed, and added instructions for testing [11:33:48] duesen: is it correct to fall through for interwiki redirects, though? that seems to defeat the privacy-protection purpose [11:43:39] tgr: it goes via Special:GoToInterwiki, so the user is prompted before leaving the site [11:43:51] is that what you mean? [11:45:04] yeah [11:45:12] where does that happen? [11:47:08] It's a bit round-about. If RedirectSpecialPage doesn't return a (usable) Title from getRedirect, it will be executed (otherwise, the actual execution of the RedirectSpecialPage is skipped). [11:47:47] Executing the RedirectSpecialPage causes an HTTP redirect. But if the target is external, that redirect does to Special:GoToInterwiki/whatever [11:48:37] That special case is actually in Title::getFullUrlForRedirect [11:49:14] oh, huh [11:49:57] updated the commit message to make that more clear [11:50:04] it's spread all over the code [11:50:19] so is that considered sufficient to avoid T109724? that's still a title with user-identifiable information in it [11:50:20] T109724: A combination of Special:MyPage redirects and pagecounts allows an external site to know the wikipedia login of an user - https://phabricator.wikimedia.org/T109724 [11:51:06] GoToInterwiki should be rendered but not redirected to, just like it happens with your user page; I don't think that will be the case here [11:53:09] tgr: i think that problem is orthogonal. If I give you a link to Special:MyLanguage/SomeObscurePage to click and then observe that the visit count for Special:MyLanguage/SomeObscurePage/it went up, then I know that your user language is italian. [11:53:13] I think what should happen there is "wrapping" $target in GoToInterwiki, if it's external, but then going into the branch [11:53:21] This is completely unrelated to the handling of interwiki prefixes [11:54:35] if Special:MyLanguage/SomeObscurePage/it is a redirect to it:SomeObscurePage and visit count for Special:GoToInterwiki/it:SomeObscurePage goes up when you visit it, that's still bad [11:55:06] SomeObscurePage/it is a redirect, I mean [11:55:52] I don't understand how that is any worse than Special:MyLanguage/SomeObscurePage increasing the count for SomeObscurePage/it directly, with no redirects or interwiki stuff involved [11:56:26] but that doesn't happen, that's the point of the branch that the patch would make external targets skip [11:56:50] the content of SomeObscurePage/it gets rendered under the address Special:MyLanguage/SomeObscurePage [11:59:37] tgr: oh, i didn't realized that. the url in the address bar changes. I suppose that'S done with JS, then? [12:00:17] probably, it's done that way when viewing normal redirect pages as well [12:01:30] language is a fringe attack vector but you could pull off the same thing with Special:MyPage (maybe even editing the suspected user's page before to be an interwiki redirect), that would be pretty concerning [12:02:46] tgr: i'll update. [12:07:07] tgr: done [12:27:55] duesen: this looks good in theory, but when I actually test it it gives a 302 to Special:GoToInterwiki [12:28:07] maybe I'm misunderstanding how to set up the test? [12:33:45] tgr: PS2 would have done that, but PS3 no longer does. I just verified by stepping though, and tracing requests with wget [12:33:49] no 302 any more [12:34:11] I'm not aware of any setup that would be needed to verify... it should just work that way now... [12:34:16] oh, duh [12:34:22] Maybe you are still on PS2 for some reason? [12:34:37] yeah, sorry, I thought I updated but apparently I did not [12:38:30] merged [12:39:07] tgr: thank you! [12:39:08] coreyfloyd: btw - see above conversation with tgr as an example of nothing ever being as simple as it seems around here ;) [15:17:14] Yes. I just read that conversation three times. I now understand it well enough that when I eventually make a similar mistake and someone points it out, I'll have a vague notion what they're talking about. 😕 [15:20:32] Yeah, and to confirm, the security issue here is with redirects from special pages in general, its implemented at a low-level and thus affects Special:MyLanguage, but it's not created for that specifically and isn't afaik as important (if at all). The main point is so that if I embed a link to "Special:MyPage/some-very-unique-token" that I won't be able to trace through public logs who you are logged in as. [15:20:41] As such https://en.wikipedia.org/wiki/Special:MyPage/some-very-unique-token redirects without an HTTP redirect [15:20:54] bpirkle: ^ [15:21:27] (e.g. as cross-domain or