[09:58:48] Krinkle: the fun part is that testing the script is really really hard. It's a gadget that helps T&S do office bans and it basically finds top most edited wikis of the person that's about to be banned and puts the legal notice on the userpage. The part is that every time it's needed, the team member needs to login as WMFOffice user which means they are logged out everywhere. I was told that the script skips the wikis addition all the [09:58:48] time unless they visit the wiki first so now after login, they just visit a couple of wikis to make sure that works [09:59:09] https://meta.wikimedia.org/wiki/User:WMFOffice/OfficeBanGadget.js#L-18 [09:59:14] Here is the part that fails [09:59:41] Maybe I should do it twice? The second API call would work? [10:02:45] Maybe I'm missing something super obvious [11:59:11] an edge login sends the browser to another wiki and creates a session there, invisibly to the user (typically by inserting an invisible 1x1px image whose source is resolved via a redirect chain that bounces between that wiki and loginwiki) [11:59:36] https://www.mediawiki.org/wiki/Extension:CentralAuth/authentication#Central_session [12:00:09] you can trigger that yourself from javascript, not user-friendly though [12:00:33] I guess we could make a helper function for it if there's a use case [12:03:07] but your problem doesn't really seem related to login [12:03:40] 1) they can just log into an incognito browser window to avoid getting logged out [12:04:14] 2) this sounds like something that should be a CLI tool or OAuth tool rather than a gadget [12:06:22] 3) I don't think ForeignApi is affected by your normal login session (on the remote wiki) at all? as Krinkle says, there should be a centralauthtoken fallback. If that doesn't work, please file a bug with timestamps. [14:17:53] Amir1: that script seems to have at least two race conditions around async handling that might explain separately why something doesn't work [16:57:06] ah, it makes sense. I should fix that part