[00:08:09] ok, making progress here but there's a different issue I think... [00:08:45] it looks like CORS is not enabled for https://en.wikisource.org/w/rest.php/oauth2/access_token and therefore I can't get an access token in the browser [00:09:04] is that how it's supposed to be? [00:09:14] unlikely [00:09:36] the entire REST API framework is relatively new [00:09:45] can you file a bug about it? [00:09:46] Access to fetch at 'https://en.wikisource.org/w/rest.php/oauth2/access_token' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. [00:09:51] oh phabricator? [00:09:51] on* [00:09:57] yeah [00:09:58] sure [00:10:17] oh, from localhost? [00:10:31] yes, but I dunno if that should make a difference [00:10:35] it's still http [00:11:00] not saying we should necessarily permit localhost requests, but right now, you couldn't even do it from wmflabs.org [00:11:14] well, there should definitely be a task about it [00:11:29] in terms of CORS you can allow from localhost if you want (your choice) [00:11:35] from file:// it never seems to work [00:11:43] yeah, I'm just not sure about the security implications [00:11:47] me neither [00:12:16] in theory we know the callback URL so maybe the CORS header should just be set based on that? [00:12:23] hmmm... yeah [00:12:26] good point [00:17:05] ok, created, added you as subscriber [00:17:43] btw should I file a separate bug about the oauth consumer form, so it doesn't offer a uri prefix for oauth 2.0? [00:17:50] it's already in a comment on the earlier task [00:18:17] I'm still trying to figure out what's going on there [00:18:50] if you are confident that the callback URI is being ignored, then yeah that should be its own bug [00:18:58] no, it's not being ignored [00:19:18] so basically the consumer request form lets you check a box that says you can treat the uri as a prefix, and use any callback uri that begins with it [00:19:25] but in fact, only exact matches are ever allowed [00:19:39] and apparently this is direct from the oauth 2.0 spec, so the oauth2-server author doesn't want to change the behavior [00:22:30] where does the spec say that? [00:23:15] the closest I can see is "The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. [00:23:19] which is pretty vague [00:25:07] tgr: see https://github.com/thephpleague/oauth2-server/issues/1085 [00:25:35] the author interprets it more strictly [00:26:13] so, regardless of spec or if wmf wants to abide by it, the reality is that the current code being used does not permit it, so the oauth consumer form shouldn't show it as an option (or the code should be changed so it works) [00:27:07] in terms of what the "right" interpretation of spec is and what behavior should be permitted outside it (if this is deemed outside of spec) I don't know, but the form isn't in sync with the code, that's all :) [00:27:22] possibly we just need to override AbstractGrant::The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. [00:27:31] oops, paste error [00:27:45] I am sure the code can be changed, yes [00:27:47] AbstractGrant::validateRedirectUri is what I meant [00:28:00] that's obviously an option too depending on what people decide [00:28:07] anyway, there definitely should be a task about the form not working as expected [00:28:24] ok, I'll make a separate one [05:13:38] not sure if I totally understand this thread: https://phabricator.wikimedia.org/T232176 [05:14:13] there's a comment here: https://phabricator.wikimedia.org/T232176#5488375 which describes the situation I'm in -- would be nice not to have to create a proxy server just to support client-side code that can be authorized to act on a user's behalf. [05:14:30] no one seems really sure if it should be supported though or how to do it [06:07:10] on the subject of OAuth in general - Why doesn't MediaWiki have support built in for it by now, instead of requiring extensions? Seems like it'd be less of a hassle for users to manage than BotPasswords, as well as being more familiar to use. [06:08:40] DSquirrelGM: OAuth 1 was a *lot* more hassle than bot passwords, it's an old protocol and not well-supported today [06:09:11] OAuth 2 is brand new; I think there are plans to move the mostly bot-password-equivalent parts into core [06:10:00] but more generally, it's complex code, for Wikimedia it does not make so much difference whether it is in core or an extension, and no one else funds MediaWiki development [06:10:32] I think it makes sense as an extension [06:10:49] Its a fairly complex component that most people dont need [06:10:58] tgr: am I right that oauth 2 is the only supported way to have client js code receive access tokens? [06:11:49] I guess for my tool on tools.wmflabs.org, I can make a little pass-through proxy to get around the CORS issue, although that's kind of annoying [06:12:23] but whatever I do, I'd like to be sure I am using the right method to do what I want -- namely, send in certain page edits from my react app [06:12:47] with as little backend development as possible (ideally none) [06:13:59] yeah, OAuth 1 does not have that kind of workflow [06:14:52] as for being less of a hassle, I meant in terms of the end user's experience - many social sites use some form of OAuth for account access and are usually centrally managed on some kind of settings page [06:15:50] Not sure i see the connection between that and extension vs non extension [06:15:50] for the end user it doesn't really make a difference whether something's an extension or in core [06:18:07] bawolff_: I think it makes sense for the consumer management to be in an extension, the part that implements the protocol in the strict sense could easily live in core, most of it is a third-party library anyway [06:19:11] Idk, i think it would be a little weird to basically just have the ui in core [06:20:06] * bawolff_ likes extensions. Extensify the world! [06:47:18] I don't really care how it's implemented as long as it works right :) [06:54:02] btw is it considered "better" to use api.php when possible over index.php? [08:07:52] ningu: yes (re: api.php) [08:20:22] except for getting article html, since index.php (via the nice URL) is cached and the action API is not [08:20:56] if I want to get a lower-res version of an image, I assume I should use thumb.php? [08:21:09] lower-res here means, say, 2000px wide rather than full-res. so not "low" res just lower [08:21:58] use the imageinfo API to get an URL for it and then use that URL [08:22:01] I know sometimes thumbnails have a particular static url assigned (at least for vanilla mediawiki) but for commons I dunno if thumb.php is the right way [08:22:05] ok [08:22:14] let me look at that [08:31:42] hrm, can I specify a page number that way? [08:34:33] if its commons, you can just use the actual url [08:34:40] As they are created dynamically [08:34:52] although imageinfo is technically more proper (and important for vanilla mediawiki) [08:35:05] and yeah, you should be able to specify a page number [08:35:37] bawolff: what "actual url"? [08:36:06] https://www.mediawiki.org/wiki/API:Imageinfo is image info docs, for page number you have to use the underdocumented iiurlparam [08:36:52] ningu: I mean the url of the file. As an example, if you know a pdf thumbnail has a url like [08:36:55] https://upload.wikimedia.org/wikipedia/commons/thumb/b/b1/GLAM_Wikimedia_Canada_-_Presentation_file.pdf/page2-180px-GLAM_Wikimedia_Canada_-_Presentation_file.pdf.jpg [08:37:04] bawolff: right now that's the url I am trying to get [08:37:08] you can adjust the page part and the 180px part, and it will just work on commons [08:37:14] ok I see [08:37:25] so the b/b1 bit won't vary? [08:37:32] It varies between files [08:37:41] yes, but not between pages in a file [08:37:43] Its an md5sum of the filename [08:37:47] correct [08:38:12] imageinfo is officially more correct in case the format changes, but that's never going to happen because it will break like everything [08:38:53] ok, so what should I call then to get the file url? if I just know the filename but not the full url? [08:39:08] if you really want to, you can use thumb.php or Special:Redirect/file. They also work, not the most officially reccomended way because they redirect you around and are less efficient, but they still work and its not like they are going away [08:39:29] yeah I am looking for the simplest way, basically [08:40:06] so, let's say I want to go from GLAM_Wikimedia_Canada_-_Presentation_file.pdf to https://upload.wikimedia.org/wikipedia/commons/thumb/b/b1/GLAM_Wikimedia_Canada_-_Presentation_file.pdf [08:41:29] it looks like I should use imageinfo for that [08:42:39] yeah, i think imageinfo is probably the simplest [08:44:35] ok cool [08:45:09] filenames are unique, right? so if I do titles=File:foo.pdf then either it will find one file or none [08:45:10] ningu: as an example: https://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&titles=File:GLAM_Wikimedia_Canada_-_Presentation_file.pdf&iiurlwidth=2000&iiurlparam=page2-2000px&iiprop=url [08:45:21] yes [08:45:25] thanks [08:45:46] You can have old versions of files, but it requires a different option to return those [08:45:53] yeah I saw that [08:46:18] ok, so I do need to use imageinfo basically, if I don't know the dirs inside thumb yet [08:48:39] The directories are deterministic, and you can determine them programtically if you want, but that's a bit more complicated [08:49:10] yeah I'd rather not rely on that [08:49:25] it's not critical enough for performance [08:49:45] it looks like if iiurlparam=page2-2000px, then iiurlwidth=2000 is superfluous [08:52:03] anyway, this should work great for what I want [08:55:06] ningu: Just as an example, from the command line you would do something like [08:55:09] size="page2-2000px-"; f='GLAM_Wikimedia_Canada_-_Presentation_file.pdf' echo "https://upload.wikimedia.org/wikipedia/commons/thumb/"`echo -n "$f" | md5sum | head -c1 `/`echo -n "$f" | md5sum | head -c2 `"/$f/$size$f.jpg" [08:55:17] but yeah, i would reccomend using imageinfo [09:45:58] ok, at long last, I finally have a proof of concept of this oauth consumer workflow. haha [09:46:17] bawolff: I guess CORS is not enabled for api.php? [09:46:37] ningu: add &origin=* to the end of the url [09:47:13] We were a bit overly paranoid when CORS first came out, so it requires an additional url parameter [09:47:26] ahh ok [09:47:28] honestly, its probably a bit overkill [09:47:28] thanks [09:52:26] ok cool [09:52:28] that's fine [09:52:45] yeah, a bit unusual given state of things as they are now [09:52:54] but nice that there's a way that doesn't require a server-side proxy [09:53:20] (which I still need for rest.php/oauth2/access_token though) [09:53:34] Oauth1 4 evah! [09:53:51] well I want to do this from browser code only... so... [09:54:09] yeah, i guess you still need server side for oauth1 regardless [09:54:24] I could do it totally in browser if rest.php enabled CORS [09:54:43] still, I can do it _almost_ totally in browser now [09:54:57] just need a proxy to get the access_token, then good to go [09:54:58] rest.php is super new, they probably want to get it a little more stable before doing that [09:55:21] I guess the origin=* thing doesn't work there [09:55:47] https://phabricator.wikimedia.org/T232176 [10:03:33] bawolff: do you need origin=* also for a CORS request that modifies the site (edits a page or whatever)? [10:03:41] I guess you need it in general for api.php [10:05:08] So if you are making a credentialed request (e.g. Using the normal login cookies. Not oauth) the origin url parameter has to be from the domain [10:05:11] ah I see you commented in that phabricator task so obviously you know about it :) [10:05:35] ok, but I'm talking about oauth2 with Authentication header [10:05:45] So from en.wikipedia.org to edit en.wikisource.org you have to add origin=en.wikipedia.org [10:05:59] I see [10:06:30] Umm, I'm not sure how CORS interacts with the authorization header. I'm more used to oauth1, where nobody is using cors at all [10:06:53] "ah I see you commented in that phabricator task so obviously you know about it :)" <-- Or maybe I jsut BS a lot on the bug tracker ;) [10:07:13] the origin=* parameter generally forces the user to be logged out i think [10:07:23] so according to this, it looks like you just need the header: https://www.mediawiki.org/wiki/OAuth/For_Developers#Making_requests_on_the_user's_behalf_2 [10:07:24] I'm not sure if that applies to oauth as well [10:07:40] right, that's the sense I am getting -- in fact that's why origin=* is not a solution to CORS in rest.php for the oauth2 endpoint [10:08:35] hmm. is authorization even a restricted cors header? probably [10:08:54] well oauth2 was literally designed to make this possible (among other things) [10:09:07] but yeah, I dunno how it interacts [10:09:21] I haven't tried it yet [10:10:50] yeah, authorization is not in CORS-safelisted request-header [10:11:10] There's certain types of requests you can make cross-domain even without CORS, but that's not one of them [10:11:31] yeah, there's some discussion of whitelisting domains [10:11:46] I guess enabling it globally is too risky (understandably) [10:11:56] for my tool hosted on wmflabs.org I can use the proxy method I guess [10:12:23] The general CORS discussion is probably quite different than using CORS for oAuth2 (I think) [10:13:11] So it may make sense to allow cors globally for oauth2 but not for the api in general [10:13:43] (I'm talking out of my hat here. I haven't even read the oauth2 spec...) [10:13:49] yes. if you look here: https://phabricator.wikimedia.org/T245474 [10:14:21] you can see the result of a discussion I had with tgr. the callback url is registered for an oauth consumer, so why not automatically allow CORS from that domain? [10:15:10] Makes sense to me [10:15:18] I am not a security expert but it seems like that would be fine [10:16:24] As someone who is a security person I wouldn't comment without reading the fine details of how oauth2 works, but at a glance it sounds reasonable [17:28:41] Hi! [17:30:09] Is there a Lua library to split an internal link into interwiki prefix, namespace prefix and page title? [17:34:05] I mean parsing ':w:fr:Wikipedia:Bot' into {'wiki'='wikipedia', 'lang'='fr', 'namespace'='Wikipedia', 'title'='Bot', 'fullTitle'='Wikipedia:Bot', …} [17:35:14] I don’t think there’s even a PHP library to do that [17:35:20] AFAIK enwiki doesn’t know what frwiki’s namespaces are [17:35:36] so I don’t think it could know whether the title should be Bot in Wikipedia namespace or Wikipedia:Bot in main namespace [17:37:21] OK, thanks! =) In fact, I don’t need to know the namespace, but I just need to split the out-wiki part from the in-wiki part. [17:38:28] So just split ':w:fr:Wikipedia:Bot' → {':w:fr:', 'Wikipedia:Bot'}. [17:38:42] then I don’t know, sorry [17:38:48] let’s hope someone else does :) [17:39:51] No problem, hoping someone else can answer =) It is in order to automatically add "Special:MyLanguage/" in appropriate place, in Meta [23:11:17] tgr: latest comments to https://github.com/thephpleague/oauth2-server/issues/1085 cite an RFC recommending that callback urls always be exact matches. seems there are too many ways to do sneaky things otherwise.