Fixed on the client side with AWB SVN 13014 (honor Retry-After headers in list generation). This is not tested live however; maybe the hotfix by @Joe dealt with the issue on the server side. Still, it's the right thing to do.

SVN 13014.

I have a simple fix in the ApiMakeList, which should cover the cases listed in T414214. Trying to test it now.

Wikimedia was updated some time last year to return error 429 (Too Many Requests) when someone is using resources too quickly, and the error is accompanied by an advisory pause time (Retry-After header). I've received in it some of my own client-side code, only ever getting a pause time of 1 second. The cure is to wait that period and retry the same call. Success isn't guaranteed though; the pause request is re-evaluated.

Update: it seems the existing fix doesn't apply to the code that processes a list.

SVN revision 13013

New fix added (SVN 13012). Don't let a RetryAfter header reset the default delay, and allow for a 503 to wait over a minute.

Already mentioned to @Reedy: the current official release should quietly retry any HTTP error after a delay that starts at 5 seconds. and escalates. But it does not honor a RetryAfter header (there is code in the tree to fix that). Also I haven't looked carefully enough at the bot mode path, and/or it could be coming from a custom HTTP submission in that plugin.

Can you also take on board the discussion in T400002? This was triggered by the enforcement of email OTP and its impact on a specific desktop app, which I first noted in T399860. At the time, there was no guidance on how to handle that via the API.

It has been fixed in the source tree, but that has not been pushed as an official build yet. I have an (almost) up to date build at https://github.com/DavidWBrooks/UnofficialAWB/releases/latest. As a bonus there's a build optimized for an ARM64 device.

Tested using different Retry-After values injected via Fiddler proxy.

Another question about response 429, sorry. Is there a range of values I can expect for Retry-After? AWB already retries <s>30</s> at least 5 seconds after any 4xx response, and I'd like to know if that needs to be updated to honor the returned value.

Re the comment: "Allow user-agents with contact information" - implies blocking UAs with no contact information. Is this referring to a subset of queries? I understood from earlier that a legacy client-side app with a UA modeled on a browser UA would be OK (unless it runs into a rate limit). Still true?

Re-upping a question I had earlier - will the servers' "Retry-After" header use seconds, or http-date, or potentially either? Of course it would be easy to figure out in my code, but it would still be good to know.

You ask clients to respect HTTP code 429 Too Many Requests. Returning to AutoWikiBrowser: the current code will simply throw a failure here. But if we want it to do something more sensible, some questions.

Thanks; I think those steps would be welcome. I already checked the code to handle EmailAuth into the AWB master source, but it hasn't been officially released yet. I will say that the chances of implementing OAuth in the client are slim.

Updated to detect EmailAuth installed extension. Finding an OATHAuth-only installation to test with can wait.

Committed 13001, implementation restricted to en wiki (where we know EmailAuth is turned on). TBD - make it more generic by checking installed extensions for EmailAuth and OATHAuth.

Re-opening because the fix causes a build failure in UnitTests Release configuration (use of WikiFunctions:Variables:SetProjectLangCode). That doesn't affect building the app.

You can close this (which, remember, is a request to document and thus continue to support the behavior). But, even without documentation, I think the only sensible solution for AWB (and any similar interactive client) is to rely on the current behavior, so I'll keep using the "token" parameter until that breaks.

After discussion in T400119, it seems that the current standard UA will be enough to prevent AWB from being blocked. That may change if an AWB bot goes crazy, in which case we would need to identify the bot in the UA, but it seems unlikely.

In T400119#11053166, @Joe wrote:

There won't be adding some magical regexes trying to ban any single case. We will make the list of user-agent regexes we block public - we want bot operators to adopt an identifiable user agent, so we can tell them apart without requiring authentication.

In T400119#11048975, @Joe wrote:

Oh sorry, I've never used AWB (or windows, in the last few decades). If it's a Windows application, as in used by users to interact with wikipedia, I guess the browser-like format you've used is ok in that case! You don't need to change anything; thanks for taking the time to check!

References task T400119.

@Joe I wasn't addressing AWB used as a bot, but as an interactive Windows app. Still, the rest of your comment seems applicable. The contact information would be the user's Wikipedia name (not the AWB authors'). We could prepend :p:ll:User: (p = project, ll = language code) if that would be better. I may need to take advice on bots' ids because I've never used that feature.

AutoWikiBrowser uses the MediaWiki API and User-Agent is WikiFunctions/n.n.n.n (Microsoft Windows NT n.n.n.n; .NET CLR 4.0.n.n). I don't know if that is distinctive enough. I guess a quick fix could be to add the logged-in user, although I'm not completely sure if any API request happens with nobody logged in yet.

AWB code is old... it used the login MWAPI until I created the fix, which uses the clientlogin API for general (not bot) use. As you suggest it doesn't use the form descriptor, but gathers the username and password from a UI dialog or its own cache. And, sorry, but I advertised a patched app before I read the above. Several users were flummoxed by the sudden login failures a few weeks ago, and I think some people have resorted to creating a bot name.

I discovered, by tracing the browser submission (duh) that the fix is to submit the auth code with the "token=**" URL parameter. That works with the clientlogin API, but I'd like a heads-up if it changes.

I discovered the (undocumented and possibly accidental) right Mediawiki API parameters. A crudely coded fix works, but I have to leave for a plane in a few minutes. It needs better error handling, but I maybe able to upload something quickly. Also as the parameters are undocumented it's not necessarily a permanent fix.

The reason for wanting this is users of AWB who frequently or occasionally change IP address have started having to either log in to the web interface and authenticate, or (current recommendation) log in to AWB using a newly-created bot account.

I'm wondering whether some wikis will still use OATH. I can put both flows into the code, but it would have to be blind (not sure I can test the OATH path to completion). To do it properly I'd have to look up how to enumerate the wiki's supported extensions.

Can any API commitment make it clear whether the 6-digit format will be eternal (or at least what format it will always have). It would be nice to bake that into client-side validation.

Thanks for the pointer, @Reedy. Glad you are more keyed in than me. The Help page has been written, but I should be able to figure out the API.

I'm most of the way there, but the API doc seems out of date. Following the example at API:Login to submit the OTC (I had to move the logintoken to the POST body), I'm told "Unrecognized parameter: OATHToken" (note - OATH not OAuth). Moving the OATHToken to the body didn't help, neither did a few capitalization changes. I'll try to find some answers in a mediawiki talk - moving to a new IP now.

There's a problem. The "login" API sends a OTC to the user's email, but that's not documented and there is no indication in the result that this happens. Detecting the failure to log in, and trying with the "clientlogin" API generates a second OTC in the user's email. I can then collect the second code from the interactive user and submit it using clientlogin with the logincontinue parameter. I haven't coded that yet because it destroys the testcase.

I think the login flow can try a clientlogin path if the regular login fails appropriately, and pop up a dialog to receive the OTC. I'm drafting that now, but will need a code review from those more familiar with the AWB intricacies. If that works, it will be helpful for users who don't think to look at the BotPwd advice in AWB Talk.

The fix was to force the menu checkbox to reflect the panel's actual visibility.

@GoingBatty https://github.com/DavidWBrooks/UnofficialAWB/releases/latest

@GoingBatty: Should be, by SVN 12943. Can you verify?

SVN rev 12943: fixed CFD, IFD, Templator windows. That's all I could find for now.

SVN rev 12942: fixed SummaryEditor, InputBox, DabForm, RuleControl

Got it. Have to break off and need time to verify; back in a few hours. Sorry to be using a public forum for DMs...

Thanks. I wasn't aware I had been added to the sourceforge inner circle :o). But not having worked with SVN until recently:

I found four more: SummaryEditor, and in WIkiFunctions DabForm, InputBox, RuleControl. Still looking through the more obscure dialogs. The attached patch verified against revision 12939.

First tranche, restoring to the old (mostly empty) resx files and all the logic in Designer files: Main, CustomerModule, CustomModuleErrors, WikiFunctions/ReplaceSpecial. Layouts verified against rev 12900. Can a developer apply them?

I'll put it on my own backlog.

I (programatically) restored all the Size and Location values from the prior Designer.cs into the resx, and it seems to work with a brief test. There was no replacement for this.ClientSize or this.MinimumSize. They didn't seem to have an effect but we should probably verify. Anyway this makes the window usable again. Offering a full source file and diffs.

Clarification: the window size on opening (in the above screenshot) is smaller than in the working sample. But when I resize the to the window to the same dimensions, it seems the layout decisions are still faulty.

I believe this was fixed a while back, but should probably be checked by someone on an older machine than mine. By the way, C# 4 using any version of the .NET Framework will accept language features up to 7.3, which is mildly confusing.

Looks good on Windows 11. Screenshots are from a build at rev 12822 and the 6.3.1.1 released version for comparison. I also checked 12830 and it's still good.

Looks like lbDuplicateWikilinks.Size should be 127,69, not 127,66. I'm surprised 3 px makes a visible difference.

Seems to work, editing by hand

I'm working through the new ones in a semi-automated way (the category "People and person infobox templates" contains some infobox subsets, and I'm excluding those, possibly unnecessarily). There does seem to be a significant number.

Yes, I've tested, in both the other-account and same-account scenarios. I keep my sources on Azure Devops because reasons, but I've attached the text output of a git diff on a base of rev 12695:

In my private build I actually named the method ClearNewMessages(), which I think is more correct. I really don't see a compatibility problem with adding this. If the HttpPost() fails, as far as I can see any exception is swallowed, but that probably means nothing will work anyway.

Yes, static calls. I instrumented it again, just before Save, and Barack Obama had used 50 cache slots. Without genfixes it uses 11 (I have a list if you want). Some will only be used during startup. Of course, modules and plugins are responsible for their own.

Fair point. My immediate reaction was maybe to put a "an article load hangs and you are using a module or plugin, look to your RE's" in the documentation. But as you say, people should know what they are doing (although the OR apparently didn't figure it out).

I think the answer to the above is "don't do that".

@A.sav: There are two workarounds.

1. So long as you keep the app open, when the network eventually returns and the original article is reloaded, right-click in the edit window will show a "Replace text with last edit" option.
2. "Options/Preferences/Editing and saving" asks AWB to snapshot your edit at intervals locally. I chose 30 seconds because you need to grab it before it gets overwritten by possibly a different title (but potentially lose 30 seconds of editing).

I should have checked: on the web version the confirmation is "Talk:Foo and its associated page have been..." so probably mobile should be consistent.

More details on the previous comment: As noted in the T371647 discussion, Framework 3.5 is not installed OOB on a new system, although it's easy enough to install by hand.

Another, not directly related, banner shell fix is described in T367178.

The AWB fix was checked in on Aug 8 and then released as part of a forced update. But that also rolled up all other changes made since the 6.3.0.1 release (with some other improvements), but any regressions that show up should be reported on the en wiki AWB project page.

The current logic (according to the Framework reference source RedistVersionInfo.cs) is:

• Use the option CompilerDirectoryPath if present
• Use the value from Executor.GetRuntimeInstallDirectory() if there is no CompilerVersion option, or it is set to 4.0
• If the CompilerVersion is 2.0 or 3.5, look in the registry for the directory, which requires Framework 3.5 installation, or a registry hack
• Any other CompilerVersion is an error.

To the comment on breaking-or-not siteinfo, please note that the AWB break (now fixed) was due to the flag removed from userinfo. That may come to the same thing; I don't know the internals.

The AWB breakage is specifically: format=xml&action=query with a body &meta=userinfo&uiprop=blockinfo|hasmsg|groups|rights returns a rights element that no longer includes <r>writeapi</r> (English Wikipedia)

Update based on setting up a new system. VS2019 Community is no longer available, although you can use Professional for a 3 months trial. Also, as I just realized, VS2022 only skips the mandatory framework update if VS2019 is installed side-by-side. Furthermore, it's necessary to make sure Framework 3.5 is installed if you want the compile to work at all.

Thanks for letting me whine and posting the update. I verified the clean build. I too am frustrated that there is no UI for these settings. But worse is that the build system doesn't issue an error message when it can't find a reference. That is definitely a bug, although whether in MSBuild or VS I don't know. Never did figure out the join between them.

Strange. Yes on the VS version. I did have UnitTests as startup (don't ask) but fixing that didn't help. And AutoWikiBrowser.exe runs just fine without NewtonSoft alongside, presumably because I haven't done anything that requires its services.

I wonder if a third party can try to repro? I guess there aren't many of us who try to build release packages anyway.

@Prati28: sent email.

I'm still trying to understand why I need a HintPath and you don't. Apparently you don't need the HintPath if the assembly is in one of four places, of which the two relevant here are (a) the output bin directory (which I hope actually means bin\release) but you said you had cleaned that (b) "paths can be specified in the project settings or configuration files". SpecificVersion false and HintPath ..\libs\NewtonSoft.json.dll work for me. While I'm here, CheckPageConverter has build errors due to 12588 but I guess that doesn't matter now.

I always build the entire AutoWikiBrowser solution (F6 in VS2019).

I apologize; I misread the changes in 12588. But I must have something different in my context from yours: I deleted all the bin and obj folders, and the Tortoisesvn checkmarks everywhere are green. I F6 the solution, and still no Newtonsoft in AWB\bin\release. But when I copy the elements of WikiFunctions csproj <Reference> entry to the AWB csproj (SpecificVersion and HintPath) and rebuild it does get copied.