Opened 6 years ago
Last modified 2 years ago
#11602 new enhancement
Make sure HTTPS-Everywhere ships with rules
Reported by: | gk | Owned by: | boklm |
---|---|---|---|
Priority: | Medium | Milestone: | |
Component: | Applications/Quality Assurance and Testing | Version: | |
Severity: | Normal | Keywords: | |
Cc: | Actual Points: | ||
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description (last modified by )
While fixing #11556 I realized that our build scripts are not failing when assembling the HTTPS-Everywhere rules breaks. No rules are shipped in our TBBs in this case. We should therefore make sure this issue is detected via our test suite(s).
Child Tickets
Change History (7)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
Description: | modified (diff) |
---|
comment:3 Changed 6 years ago by
Description: | modified (diff) |
---|
comment:4 follow-up: 5 Changed 6 years ago by
We currently have a test that check that https-everywhere is working by visiting an http URL which has a rule (http://www.mediawiki.org/wiki/MediaWiki) and checking that it results in visiting the https URL (we also check that it doesn't do that when the extension is disabled, in case the website starts redirecting automatically one day). So I think this test would have detected this problem.
But I can also add a test that checks that rulesets.sqlite exists and is not empty just to be sure.
It would probably be a good idea too to check for any exception thrown during TBB start-up, I will check if we can detect that (or if mozmill already makes an error in that case).
comment:5 follow-up: 6 Changed 6 years ago by
Replying to boklm:
We currently have a test that check that https-everywhere is working by visiting an http URL which has a rule (http://www.mediawiki.org/wiki/MediaWiki) and checking that it results in visiting the https URL (we also check that it doesn't do that when the extension is disabled, in case the website starts redirecting automatically one day). So I think this test would have detected this problem.
Nice! Does the test catch corner-cases like a redirection to an HTTPS site on mediawiki's side itself? I could imagine that they implement that one day and then (depending on how the test works) passing might not say much about a functioning HTTPS-E anymore...
But I can also add a test that checks that rulesets.sqlite exists and is not empty just to be sure.
It would probably be a good idea too to check for any exception thrown during TBB start-up, I will check if we can detect that (or if mozmill already makes an error in that case).
Either way seems fine at least to detect the issue I encountered.
comment:6 Changed 6 years ago by
Replying to gk:
Nice! Does the test catch corner-cases like a redirection to an HTTPS site on mediawiki's side itself? I could imagine that they implement that one day and then (depending on how the test works) passing might not say much about a functioning HTTPS-E anymore...
Yes, we have a second test that disable HTTPS-E, and loads the same URL to check that it is not redirected to https. So if one day they start redirecting to https on their side, this second test should fail (and we'll have to update the test to use an other URL).
comment:7 Changed 2 years ago by
Severity: | → Normal |
---|
Set all open tickets without a severity to "Normal"
One way to do this is to check whether rules.sqlite in HTTPS-E's defaults directory is existing. An other way would be to look for a special exception thrown during TBB's start-up. (the mozStorageConnection is failing due to the missing rules.sqlite)