[11:28:55] !log tools.stewardbots rm -r migration [11:30:07] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.stewardbots/SAL [19:36:08] there is no way to get an oauth consumer secret back if it's lost, right? [19:40:51] correct ningu [19:41:00] ningu: it is technically possible with WMF production database access, but in practice the last time I tried to help someone recover one it did not work [19:41:10] yeah I figured, no worries [19:41:12] so I would suggest just making a new grant request [19:41:31] I may not even need to get it back -- this was for testing anyway and I think the part that requires it is already tested :) [19:42:11] also thx for merging my Striker patch [19:42:22] now you just need to deploy it bd808 [19:43:12] Majavah: working on it. I'm trying to plug up some other bugs and wishes in the say release [19:43:35] deploying a new build of Striker is not fun so I don't want to waste the trip :) [19:46:15] bd808: can you approve ia-upload-dev 1.2? [19:59:04] ningu: {{done}} [19:59:27] thanks! [19:59:49] I lost credentials when I deleted and recloned the repo and forgot it had that file in it :P [20:00:21] I would be lost without using my password manager to backup such things :) [20:00:45] yeah, I would do that if it was more permanent [20:06:26] bd808: the oauth access token is tied to the consumer, right? [20:06:40] correct [20:06:51] but you can't infer the consumer key from the token itself, right? [20:07:23] I realized an issue I was experiencing is an access token was already stored, but because of the new consumer id it was invalid [20:07:30] but the tool didn't realize that [20:08:09] ningu: yeah, if you are using a new grant then you need to invalidate any cached tokens you may have on the application side [20:08:14] hrm... I have an idea how to do that [20:08:38] I think basically whenever the error comes back as mwoauth-invalid-authorization it should clear those [20:09:24] unless your tool does things on behalf of the user when they are not logged in (like bot edits or some work queue) I wouldn't even store the OAuth token you get from them authenticating permanently. [20:09:43] bd808: oauth secrets are hashed. You can retrieve them via shell.php. [20:10:04] that said, there shouldn't really be a need for it. [20:10:06] bd808: this is stored in a cookie I believe [20:10:15] it comes down to the same issue though [20:10:31] tgr: in theory yes. The last time I tried I couldn't figure out which secret was used in the hashing these days. The OAuth2 refactoring seems to have changed all that a bit [20:10:35] just reset the secret and update your app. Users will have to reauth but that's not a big deal. [20:11:01] tgr: the issue is the way the app is written, it will see the users have an access token and assume they are auth'd and try to use it [20:11:12] so I need to detect that the user is not, in fact, authed [20:11:20] but remember it after they reauth [20:11:32] one sec I will link to code [20:11:41] tgr: if you know where the master secret key is kept these days, an edit to https://www.mediawiki.org/wiki/User:BDavis_(WMF)/Notes/Recover_OAuth_secret would be appreciated :) [20:11:43] just add a version number to the token. [20:12:03] if the version number is outdated or missing, discard the token. [20:12:06] https://github.com/kamholz/ia-upload/blob/master/src/Controller/UploadController.php#L112 [20:12:11] tgr: ok yeah, good idea [20:12:24] I was going to do something like that [20:13:28] can the php session value be an array with key/value? [20:13:46] apparently it can [20:14:59] a php session can store anything that is serializable :) [20:15:58] all: There is a poll up for picking the favicon on gerrit.wikimedia.org -- https://phabricator.wikimedia.org/V21 [20:20:53] bd808: mwscript shell.php metawiki; MediaWiki\Extensions\OAuth\Backend\Utils::hmacDBSecret( MediaWiki\Extensions\OAuth\Backend\OAuth1Consumer::newFromKey( wfGetDB( DB_REPLICA ), )->getSecretKey() ) [20:20:59] if I remember correctly [20:22:11] for OAuth2 it would be MediaWiki\Extensions\OAuth\Entity\ClientEntity instead [20:24:18] it would give the same results as your notes, as far as I can see [20:27:38] tgr: ack. that does seem work. I think what I got confused about the last time I tried this is that apparently in prod we are now falling back to $wgSecretKey which was not always the case (but maybe $wgOAuthSecretKey used to just shadow $wgSecretKey) [20:47:26] hello @bd808 was wondering if i could give a nudge about ssh, no rush (but there's a timeline for GSoC, so that :3) [20:48:07] qedk: if you are in a hurry, you probably need to rethink your code. [20:48:36] I think we can add the ssh client you want, but I don't have a guess as to when it will get done [20:48:47] there's about a month to go, are you guessing before or after? [20:49:01] I don't have a guess as to when it will get done :) [20:49:11] ahh alright, thanks anyway! [20:49:23] is there a reason you can't use HTTPS git push? [20:49:39] we are using deploy keys [20:49:47] qedk: https://developer.github.com/v3/guides/managing-deploy-keys/#https-cloning-with-oauth-tokens [20:49:53] ^ [20:54:26] will try the git credential-store 🤞 [21:19:04] they haven't opened one of those in my neighborhood yet [21:27:28] you have to ask torvalds nicely [23:58:40] Majavah: if you wanted to test and review my Striker patches messing with toolinfo things that would be appreciated :) -- https://gerrit.wikimedia.org/r/p/labs/striker/+/dashboard/default:open