refs: https://github.com/TryGhost/Toolbox/issues/595
We're rolling out new rules around the node assert library, the first of which is enforcing the use of assert/strict. This means we don't need to use the strict version of methods, as the standard version will work that way by default.
This caught some gotchas in our existing usage of assert where the lack of strict mode had unexpected results:
- Url matching needs to be done on `url.href` see aa58b354a4
- Null and undefined are not the same thing, there were a few cases of this being confused
- Particularly questionable changes in [PostExporter tests](c1a468744b) tracked [here](https://github.com/TryGhost/Team/issues/3505).
- A typo see eaac9c293a
Moving forward, using assert strict should help us to catch unexpected behaviour, particularly around nulls and undefineds during implementation.
refs https://github.com/TryGhost/Toolbox/issues/292
- There are couple of reasons why we don't want to include the query string information in the outgoing notification emails:
- 1. Security - we can expose the Content API key to an unauthorized person. The emails go out to administrators, so they have access to this data anyway. But for example they might forward full email content to someone from “tech team” or whoever is not really authorized to see it.
2. It looks a bit ugly and could be waaay to long breaking the email layou
refs https://github.com/TryGhost/Toolbox/issues/292
- The version mismatch middleware middleware is the best place where the information can be assembled for the APIVersionCompatibilityService to handle. We need API key identification information to be able to pick up the integration name when sending a notification email to the administrators
refs https://github.com/TryGhost/Toolbox/issues/292
- There was a typo in the variable name - req.originalURL is NOT does not exist on express' reqest object
- Added tests to avoid similar mistake again
