The solution is pretty simple. All Wikimedia project URLs start with https://. If Huggle 2 uses http:// for Wikimedia sites, that needs fixing!

Yes, I tried to replace all occurences of http:// in config.txt with https:// the error does not occur, but I get another error:

"Failed to load configuration pages!: You must be logged-in to have a watchlist."

Screenhot:

CC @Petrb - I really don't know the Huggle code to tell you what to try next.

Wasn't https forced already long before "28/29 Jan 2016"? Nevermind, there are locations in the vb-sourcecode where http is hardcoded. Also even if there were https, afaik there would be per default no cert validation.
This must be fixed in the old visual basic code. but the devs/Petr don't support HG2 any more.

For vb-devs.: the repo is still there: https://github.com/huggle/huggle, a good place to start fixing this is in /Requests/Requests.vb

or...or...Download Huggle 3.x.x instead. And mark 2.x.x as defunct and move on.

In T126357#2012865, @Se4598 wrote:

Wasn't https forced already long before "28/29 Jan 2016"?

Yes, for GET/HEAD requests, for the better part of a year now, by redirecting them all to https:// (and some other reinforcements like setting the Strict-Transport-Security for UAs that honor it, and adding our sites to the STS-preload list modern browsers use, and HTTPS-Everywhere lists, etc).

However, POSTis special ( T105794 ): some automated UAs (bots, scripts) use POST almost exclusively (or at least, start there), and there's no sane way to redirect it that won't break some (or more likely, most) automated UAs, and even if we did redirect it that doesn't stop the initial leak of data that happens on-request before the redirection. The only real fix for these UAs is to get them to use https:// URLs in the first place, on their end. So incoming insecure POST has continued to be allowed for fear of breaking things. We're finally getting back around to trying to find ways to clean that up and enforce it, and one of those was the recent change to have the API return the "HTTP used where HTTPS expected" stuff in https://gerrit.wikimedia.org/r/#/c/267207 . Eventually we'll have to set some terminal date and actually break these insecure POST requests so that they don't work at all...

In T126357#2012865, @Se4598 wrote:

Wasn't https forced already long before "28/29 Jan 2016"? (...)

Since this day, the API throws a warning, the "HTTP used when HTTPS expected" warning.

In T126357#2012994, @Luke081515 wrote:

In T126357#2012865, @Se4598 wrote:

Wasn't https forced already long before "28/29 Jan 2016"? (...)

Since this day, the API throws a warning, the "HTTP used when HTTPS expected" warning.

This warning was added to MediaWiki in rMW240f789c8926: Log user-agents that are using HTTP when HTTPS is preferred specifically to help notify Action API users of T105794: Insecure POST traffic prior to a forceful termination of the current hole in our HTTPS implementation.

The gaps in Huggle2 throwing errors would correspond to the rollbacks of 1.27.0-wmf.11 which originally included the change. Once wikis got 1.27.0-wmf.12 the warning was back in the production codebase.

This is just a warning, so it was not intended to break clients. In addition to the HTTPS problems, it appears that Huggle2 does not support warnings in the Action API response well. This is likely to be a continuing source of issues as all major (and most minor) Action API interface changes are preceded by a period of emitting a warning.

Got it! Just commenting out the aborts and exit subs does the trick.
In Login.vb

    Class LoginRequest : Inherits Request
...
        Protected Overrides Sub Process()
...
            If ConfigResult.Error Then
                'Abort(ConfigResult.ErrorMessage)
                'Exit Sub
            End If

In ConfigRequests.vb

    Class ConfigRequest : Inherits Request
...
        Protected Overrides Sub Process()
... 
            If Result.Error OrElse Config.ProjectConfigLocation Is Nothing Then
                'Fail(Msg("login-error-config"), Result.ErrorMessage)
                'Exit Sub
            End If

Hi, could someone be so kind to put a compiled version including this hack to http://tools.wmflabs.org/huggle/files/huggle%202.1.26-a.exe ?
Thanks in advance.

Yes, I will do later today. Have to remove some extra debugging code first.
I also have added a bit of code to strip the page header, sidebar and footer out of the diff window--see Huggle Feedback section.
Do I create a version "huggle2.exe" with internal version 2.1.26 and then rename it to "huggle 2.1.26-a.exe"?

And... how do I go about to actually put it there?

Of course I can't upload the exe.
And anyway, it doen't work anymore, see Feedback WrongToken section: both H3 and H2 are now unable to log in.

Commenting out the aborts may get huggle working but only with its internal fallback config page, so this only works for english wp and uses probably some ancient configs, including some very old warning templates only.

By the way, I haven't commented out the aborts. I have trapped the errors that are mere warnings about HTTPS. Corrected a few bugs too. Works pretty good now.

I have left a new version 2.1.27.6 in our shared dropbox, ready to be picked up, tested, honed and published by Petrb.
Caught bug reading resources file WarningSummaries.txt by ConfigIO.vb.
Separator char CRLF was used instead of vbLf, resulting in a corrupt lookup table.
I made the config reader try both split schemes.
User warning levels (1,2,3,4) correctly appear in the coloured blobs in the queue again.