[19:19:23] anomie: https://gerrit.wikimedia.org/r/#/c/RelPath/+/570940/ :) [19:28:12] Krinkle: Would that lib get confused on Windows if the URL's path contains backslashes? [19:34:26] anomie: as-is it doesn't grok urls, //foo becomes /foo and I don't even want to know what it does to scheme://. But we could move the URL handling there as a new method [19:34:32] In terms of disk paths, I believe it has Windows support. [19:34:45] but it's been a while. test cases welcome :) [19:35:50] Krinkle: That was the point, if you run it on Windows will it treat backslash as a path separator even though RFC 3986 only wants forward slash? [19:36:51] anomie: the current methods are for file system paths, not URLs. We'd add them as separate methods with little or no common code. It's just a few dozen lines of code. [19:37:11] I do see that Guzzle has its self split between three packages, with the url interpreation being in one of them. It's still fairly large and with unrelated dependencies, but if those aren't too volatile (which would greatly restrict ability to use CSSMin if you already have Guzzle), then we could maybe use that. [19:37:37] Oh, I misunderstood. The proposal is that "wikimedia/relpath" would also have URL parsing and manipulation? [19:37:42] Yeah [19:38:54] This is the kind of logic that just works. Using upstream tends to add more complexity and restrictiveness with basically no support or bug fix or other benefit ever arriving. So it's an indefinite cost with no payback. I'd even be inclinced to inline it in a private method within CSSMin if there's no easy path forward. I say that still being very much for re-using etc, but not for everything. [22:26:15] tgr_: I have an OAuth related question that I would like you opinion on. We are working to switch canonical Toolforge URLs from https://tools.wmflabs.org/$TOOL/ to https://$TOOL.toolforge.org/. This is going to break OAuth grants by changing the callback URL. The question is if we can use direct database edits (or a new maintenance script I could write) to update existing grants or if we should force folks to create an entirely new grant. [22:27:50] bd808:I recall someone saying this would be a gradual switchover, with the two URL patterns coexisting for a while [22:28:14] yeah, it will at least start as an opt-in thing [22:28:29] but I'm trying to think of things that will trip people up [22:28:30] in that case, no, the database edit would break the old URL [22:28:51] right, I would only want to change for tools that opt in [22:29:15] basically my thinking is that once you opt-in to the new scheme the old URLs will refirect [22:29:39] so visit https://tools.wmflabs.org/sal/ and get a 301 to https://sal.toolforge.org/ [22:30:10] *redirect [22:30:10] apart from that, there are three problems: the tool must send the correct URL (if it uses the dynamic callback option), the server must accept the URL, the server must redirect back to the correct URL [22:30:29] agreed [22:30:36] the third can presumably be handled on the apache level [22:32:36] the second can be hacked around, with database edits or even adding some kind of hook which recognizes this is a toolserver URL and accepts both variants (a bit tricky because of signatures but doable, and would actually be useful for other things such as dealing with MediaWiki URL handling messes like T59500 and T74186) [22:32:37] T59500: Impossible to use https://www.mediawiki.org/wiki/Special:OAuth/initiate?format=&oauth_callback= style URL - https://phabricator.wikimedia.org/T59500 [22:32:37] T74186: Varnish: Mobile site redirect interferes with OAuth authorization process - https://phabricator.wikimedia.org/T74186 [22:36:08] ...I guess I'm confusing things, those tasks are about problems with the URL where the client submits the request, not the return URL [22:36:25] so there isn't actually an overlap [22:37:04] anyway, I see no problem with it, other than the tool has to switch at the exact same time as the server [22:37:30] I haven't had a chance to look at the OAuth2 additions yet, not sure if anything is different there [22:38:35] ok. good points all. The simple answer is to tell folks to just request a new grant and ping me to approve. The more complicated answer is that I could figure out how to edit the existing grants on demand. [22:38:53] if you want to avoid haing to coordinate with the tool, we'd need some kind of hack/hook to relax callback URL validation, which does not seem complicated [22:39:19] yeah, magic would be nice, but probably a big pain [22:39:42] just duplicating all the grants is certainly is the easiest conceptually, a bit annoying on the consumer management side [22:41:00] editing on demand would just be a trivial DB change (given OAuth is somewhat security-sensitive, it would be nice to have a maintenance script for it which also logs, but I don't think it's absolutely necessary) [22:41:39] magic seems the easiest to me, although at some point you'd need to edit or replace the consumers anyway [22:42:01] still, it seems less effort than coordination [22:42:38] assuming the URLs are guessable and it's guaranteed another user cannot get a hold of the other variant [22:43:01] (it's pretty cool that this is happening BTW!) [22:51:09] ...on the other hand, magic wouldn't be applicable to tools which have a non-dynamic callback URL, so maybe it is not worth the effort [22:53:50] FWIW, if you do want to magic, the place for that is https://github.com/wikimedia/mediawiki-extensions-OAuth/blob/39182b03b05df4814e544516805c6382f651018d/includes/backend/MWOAuthServer.php#L96 (which apparently has a fair bit of magic already)