Travis placed an unnecessary breaking restriction on our tests and failed to respond within 72 hours to our complaint. This has forced us to introduce Github Actions to manage our testing. This is hopefully a temporary measure while Travis either gets itself together or we find a non-Github requirement.
* Add commentary explaining why things are done the way they are.
* Delete steps that were added for debugging.
* Pass `--no-save` when installing `ep_etherpad-lite`.
* caching_middleware: fix gzip compression not triggered
* packages: If a client sets `Accept-Encoding: gzip`, the responseCache will
include `Content-Encoding: gzip` in all future responses, even
if a subsequent request does not set `Accept-Encoding` or another client
requests the file without setting `Accept-Encoding`.
Fix that.
* caching_middleware: use `test` instead of `match`
* add tests
* make code easier to understand
* make the regex more clear
* Avoid bashisms.
* Simplify `sed` of `settings.json`.
* Wrap long lines.
* Define and use the conventional log functions.
* Quote variable expansions.
`tests/frontend/travis/runner.sh` transforms `settings.json.template`
and overwrites `settings.json`, so creating `settings.json` doesn't
have any effect. Change the Travis setup to mutate
`settings.json.template` instead of `settings.json`.
* Fix bad paren placement in `/javascript` handler
This fixes a bug introduced in commit
ed5a635f4c.
* add regression test for #4495
* Move `/javascript` test to `specialpages.js`
Co-authored-by: webzwo0i <webzwo0i@c3d2.de>
Some authentication plugins use the users defined in the `users`
object but ignore the `password` and `hash` properties.
This change deletes all of the filtering logic, including the logic
that filters out users that have both `password` and `hash` properties
defined. I could have kept that check, but decided to remove it
because:
* There's no harm in defining both `hash` and `password`.
* Allowing both makes it easier to transition from one scheme to
another.
* It's fewer lines of code to maintain.
If `settings.json` contains a user without a `password` property then
nobody should be able to log in as that user using the built-in HTTP
basic authentication. This is true both with and without this change,
but before this change it wasn't immediately obvious that a malicious
user couldn't use an empty or null password to log in as such a user.
This commit adds an explicit nullish check and some unit tests to
ensure that an empty or null password will not work if the `password`
property is null or undefined.
This makes it possible to disable `contentEditable` for certain
elements in some circumstances (e.g., on links so that users can click
on them normally).
Richard Hansen