refs #9178
## Rule
- do not use the database in unit tests
- re-add correct unit tests if you work on something which is not tested properly (we have to bring them back at some point, but without using the database)
no issue
- this npm package is very out-of-date
- it shows 5-6 security warnings
- i don't really know why this grunt command exists
- it was added 5 years ago: f84d3d32e5
refs #9389
- eslint@5.12.1, eslint-plugin-ghost@0.1.0, grunt-contrib-clean@2.0.0, grunt-contrib-uglify@4.0.0, grunt-eslint@21.0.0, grunt-mocha-cli@4.0.0, grunt-shell@3.0.1, mocha@5.2
.0, nock@10.0.6, rewire@4.0.1
All of them dropped Node v4. I was not able to find any other big breaking changes, which affect us right now.
refs #9389
- https://github.com/sinonjs/sinon/blob/master/CHANGELOG.md
Breaking changes for Ghost:
- no need to create a sandbox anymore, each file get's it's own sandbox
- just require sinon and use this sandbox
- you can still create separate sandboxes with .createSandbox
- reset single stubs: use .resetHistory instead of .reset
This is a global replace for any sandbox creation.
---
From https://sinonjs.org/releases/v7.2.3/sandbox/
> Default sandbox
> Since sinon@5.0.0, the sinon object is a default sandbox. Unless you have a very advanced setup or need a special configuration, you probably want to just use that one.
refs #9389
- https://github.com/visionmedia/superagent/blob/master/History.md#400-2018-11-17
- breaking changes don't really affect us
- .end(…) returns undefined instead of the request. If you need the request object after calling .end() (and you probably don't), save it in a variable and call request.end(…). Consider not using .end() at all, and migrating to promises by calling .then() instead.
- this could be changed, but it's not required
refs #10286
- this is just a hotfix for v0.1
- we keep the x_by fields for now and deprecate them
- as soon as an integration updates/inserts a resource, we just store the owner ID
- we currently work on a new concept for v2
- v2 no longer exposes or uses x_by, see https://github.com/TryGhost/Ghost/pull/10294
- we need to iterate on this change, because we currently use the naming `context.api_key_id` in the auth/API layer
closes#10391
- We use "relative protocol" urls for gravatar images, which were
incorrectly getting treated as relative path urls.
- Refactored getBlogUrl calls into const
refs #9865
- small refactoring to make both session and admin api key handling similar
- admin api key authentication is still disabled, but easy to enable
- added proof test how to authenticate using admin api keys
refs #9865
- the outer authentication layer wants a consistent interface of each authentication package
- admin.authenticate
- session.authenticate
- furthermore, there is no need to put the full feature into the exposed function name
refs #9865
- Added `auth.authenticate.authenticateAdminApiKey` middleware
- accepts signed JWT in an `Authorization: Ghost [token]` header
- sets `req.api_key` if the token is valid
- Updated `authenticatePrivate` middleware stack for v2 admin routes
refs #9865
This updates all current permissible methods to use the new function
signature which includes the hasApiKeyPermissions parameter. It also
makes sure that the hasApiKeyPermissions argument is taken into account
whenever checking before returning a resolved promise.
To be continued. This is just a tiny part of the big picture. None of these changes are fully committed to stay as they are.
refs #9865
- Enabled the permissions module to lookup permissions based on an api_key id.
- Updated the "can this" part of the permissions service to load permissions for any api key in the context, and correctly use that to determine whether an action is permissible. It also updates the permissible interface that models can implement to pass in the hasApiKeyPermissions param.
* Updated docs links to best equivalents
- Our documentation has been overhauled, this updates the all the old links sprinkled through Ghost
* Update integrity hash
no issue
- Fixes a case where a post that doesn't belong to a collection throws a 500 Resource Not Found Error
- This should be a 404 Resource Not Found error
- 500 suggests something went very wrong and is our fault,
- but this is a user error where the collections or posts are misconfigured, and some content doesn't have a home
closes#10383
- Upgrades got to 8.3.2, which contains better error handling and resolves the issue with uncaught exceptions
- Note: Got 9.x stream doesn't support Node v6
- Requires us to hardcode http:// for xmlrpc because there is a breaking change where got now defaults to https instead of http
