[00:00:09] <Cyberpower678>	 Alright.
[00:00:25] <Cyberpower678>	 I think it should show something
[00:02:13] <Cyberpower678>	 urbanecm: ^
[00:03:15] <urbanecm>	 Cyberpower678: and it's the cookie that was suspected o nthe task :/
[00:03:35] <Cyberpower678>	 I take it, that means it worked.  Care to share? :-)
[00:04:57] <Cyberpower678>	 So that means this blocked user logged in to the tool recently, and basically distributed his cookie block to the tool?
[00:05:05] <urbanecm>	 yeah
[00:05:14] <Cyberpower678>	 Seems like a great way to troll
[00:05:51] <Cyberpower678>	 Cookie blocks and OAuth should not mix.
[00:06:44] <urbanecm>	 this is the offending cookie: enwikiBlockID=13471853%redacted
[00:06:53] <urbanecm>	 13471853 is the block ID
[00:07:34] <urbanecm>	 the redacted part is a signature generated by the srv
[00:07:47] <urbanecm>	 (to ensure you can't forge the cookie)
[00:08:24] <Cyberpower678>	 Can you delete to unset the block?
[00:08:38] <urbanecm>	 since the tool's IP's immune from autoblock, probably
[00:09:02] <urbanecm>	 dunno if it spreads to IP/acc by cookie
[00:09:03] <urbanecm>	 probably not
[00:09:32] <Cyberpower678>	 But the root problem should be fixed.  OAuth sessions should not be receiving cookie blocks.
[00:09:45] <Cyberpower678>	 As that will disrupt everyone else's session.
[00:10:14] <urbanecm>	 I'd say it's an issue in the client. 
[00:10:36] <Cyberpower678>	 Why's that?
[00:10:41] <urbanecm>	 if cookies are accepted, there should be separate cookie jars for every tool user
[00:10:48] <Cyberpower678>	 The bot is simply doing it's usual cookie jar thing.
[00:11:03] <urbanecm>	 yeah, but it shares a cookie jar globally, for all user accounts
[00:12:23] <Cyberpower678>	 urbanecm: considering that I need an OAuth header for every request on behalf of the user, I didn't really think user specific session cookies were being sent to the cookiejar
[00:12:50] <Cyberpower678>	 The moment I drop the header, it would become an IP editor
[00:12:58] <urbanecm>	 yeah, there's no session. it'd work perfectly if you stop accepting cookies imo
[00:13:12] <Cyberpower678>	 Hmmm...
[00:13:29] <Cyberpower678>	 Let me think about the implications on that one.
[00:14:27] <urbanecm>	 but sharing cookies when more than one account edits the site can have huge implications
[00:15:00] <urbanecm>	 if MW stores something secret and user-specific in cookies
[00:15:42] <Cyberpower678>	 Hmmm.
[00:16:13] <Cyberpower678>	 I was having it backwards in my head.  Every user got it's own cookie in the jar.
[00:16:26] <Cyberpower678>	 Not every user shared the same cookie file in the jar.
[00:17:22] <urbanecm>	 well cookie sharing has to happen
[00:17:36] <urbanecm>	 otherwise i wouldn't see the blockID cookie in my output
[00:19:12] <urbanecm>	 Cyberpower678: anyway, good luck at fixing the bug :)
[00:19:14] <urbanecm>	 glad it's known
[00:19:40] <Cyberpower678>	 Yea, I'm trying to drop use of the cookie jar for just OAuth user request
[00:21:00] <Cyberpower678>	 The interesting problem is that the code initializing CURL with cookies is shared between the actual bot and the single user requests.
[00:26:14] <Cyberpower678>	 urbanecm: can you run it now.
[09:25:25] <elukey>	 Hi folks! I am wondering if anybody could help with https://phabricator.wikimedia.org/T304872
[09:26:27] <dcaro>	 let me give it a look
[09:27:17] <elukey>	 thanks!
[10:02:45] <dcaro>	 !log admin restarting keystone (T304918)
[10:02:48] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL
[10:02:48] <stashbot>	 T304918: cloud: horizon login fails with invalid credentials - https://phabricator.wikimedia.org/T304918
[10:36:08] <Rook>	 !log paws upgrading pywikibot 702f21dfe79e558d504c34474b295f1b8a5f75bb
[10:36:10] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Paws/SAL