Page MenuHomePhabricator

Huggle 2 fails on HTTP used when HTTPS expected
Open, LowestPublic

Description

When loggin on to Huggle 2.1.26 (most recent version) we get error message:

"Failed to load configuration pages!: HTTP used when HTTPS was expected".

This occurs on Win XP sp3, Win 7 pro, Win 8.1, Win 10.
The problem started around 28/29 Jan 2016.
Between (approx.) 2 and 4 Feb 2016 there was no problem.
Since 5 Feb 2016 the problem came back and persists at least till today 9 Feb 2016.
Problem was mentioned at Huggle Feedback.
Screenshot:

There is no problem in Huggle 3, but that one has many problems and some of the regular vandalism fighters still prefer Huggle 2.

Thanks for looking into this!
Cheers - DVdm

Event Timeline

DVdm created this task.Feb 9 2016, 6:38 PM
DVdm raised the priority of this task from to Needs Triage.
DVdm updated the task description. (Show Details)
DVdm added projects: Huggle, HTTPS, HTTPS-by-default.
DVdm added a subscriber: DVdm.
BBlack added a subscriber: BBlack.Feb 9 2016, 6:47 PM

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

DVdm added a comment.Feb 9 2016, 7:01 PM

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:

BBlack added a subscriber: Petrb.Feb 9 2016, 7:03 PM

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

Se4598 added a subscriber: Se4598.Feb 9 2016, 9:41 PM

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.

BBlack added a comment.EditedFeb 9 2016, 10:10 PM

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...

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.

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.

DVdm added a comment.Feb 10 2016, 10:14 AM

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
Jkbw added a subscriber: Jkbw.Feb 11 2016, 3:43 AM

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.

DVdm added a comment.Feb 11 2016, 7:00 AM

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?

DVdm added a comment.Feb 12 2016, 7:23 AM

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.

Petrb added a comment.Feb 12 2016, 4:38 PM

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.

Restricted Application added a project: Operations. · View Herald TranscriptFeb 23 2016, 6:12 PM
DVdm added a comment.Feb 23 2016, 6:20 PM

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.

DVdm added a comment.Mar 2 2016, 3:13 PM

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.

Se4598 triaged this task as Lowest priority.Mar 23 2017, 8:52 PM