no issue
- removed unused environment variables
- hardcoded Node v10 as this is what 2.x supports
- removed extra git line that is now a feature of the checkout Action
back-ported from 64ed246d03
- added an `externalRequest` lib
- uses same underlying `got` module as our `request` lib
- uses `got`'s `beforeRequest` and `beforeRedirect` hooks to perform it's own dns resolution for each url that's encountered and aborts with an error if it resolves to a private IP address block
- includes a bypass for Ghost's configured url so that requests to it's own hostname+port are not blocked
- updated v0.1, v2 and canary oembed controllers to use the `externalRequest` lib
no issue
- we were using the `Ghost` user agent when making the initial page request but not when making a subsequent rel="alternate" oembed request
- added a 2sec timeout to the rel="alternate" oembed request to match the initial page request
refs 5efef45dd0
- v0.1 oembed endpoint supported schemaless URLs according to the tests so support was added to the endpoint
- updated the tests to use a valid oembed response
- updated the tests to expect a validation error rather than an internal server error when the remote endpoint is not available
refs https://github.com/TryGhost/Ghost/issues/10471
- Allow page resource endpoints to accept HTML source. This behavior is the same as the post's resource introduced with e9ecf70ff7372f395b8917340805148bc764e2ef
- The functionality was most likely missed when post split into posts & pages was happening.
- Added symmetric changes to API v2.
refs https://github.com/TryGhost/Ghost/issues/10679
- this was a regression introduced after extracting our url-utils package
- `urlUtils.htmlRelativeToAbsolute(html)` will return `null` rather than an empty string if `html` is explicitly passed in as `null`
no-issue
Our function for determining cors options created a new instance of URL
without wrapping it in a try/catch which meant any failures to parse the
URL bubbled down as a 500 error.
500 errors are commonly used for alerting at the infrastructure level,
and this error is definitely one caused by a badly configured client, so
we wrap the construction and crap out with a Bad Request Error (HTTP
400) if it fails.
no issue
We added 2 new member subscription settings - `allowSelfSignup` and `fromAddress`- with defaults as `true` and `noreply`, this migration sets default values for both settings for users migrating from previous version and cleans up intermediate naming for `allowSelfSignup`.
