refs #9866
- prep for v2
- you can better unit test the permissible function
- this avoids copying over the permission handling to v2 controller
- it was possible to move this logic into the model layer, because we now support `unsafeAttrs`
no issue
- last commit failed on mysql
- reverted added a new user to knex test utility
- added the user in the target test
@TODO: we should in the future add resources per test, without using a "global" set,
otherwise you always run into trouble that you have to update a lot of tests when you add a new resource to the test set
refs #9866
- try to keep API interactions for routing tests in a single place, because it gives a better overview
- tiny improvement
- there are lot's of other things we could do, but we want to limit the changes for now
Goal:
e2e/api/v0.1
utils (local)
e2e/api/v2
utils (local)
utils
api (shared)
refs #9866
- the global utility should for now not generate API urls
- we only have one test which generates the API url
- for now it will live in this test file
- if we have multiple cases, we can reconsider this
refs #9866
- the sdk does not use the url utility
- it just respects what you pass in
- there is no need to test this behaviour for multiple API versions
refs #9866
- we want to keep shared API helpers
- the local utility just wraps this call and forwards the correct url
- ability to override the behaviour completely
refs #9866
- we would like to avoid doing for each api version e.g.
testUtils.API.getQueryUrl('webhooks/', v2)
testUtils.API.getQueryUrl('webhooks/', v3, admin)
- the URL should be easily accessible per api version routing folder
- so i thought it makes the most sense to add a local utils file
e.g. localUtils.API.getQueryUrl('webhooks/') => returns target api url for target api folder by default
e.g. localUtils.API.content.getQueryUrl('webhooks/') => returns content api url for target api folder
- it also makes it easy for us to copy the routing tests over without changing anything
- we just need to provide the local utility
no issue
- now that we have a concept of `unsafeAttrs`, we can move the custom permissions to the invite model
Why doing now?
A) We won't copy this controller code to v2.
B) Makes it easier to unit test this behaviour
no issue
- why? this is a unit test (!)
- we start+stop Ghost in the routing tests a lot, this implicit tested
- it has no priority for now to move this test to a unit test
- this was the only module test, removed related grunt tasks
* Added admin specific auth{enticate,orize} middleware
refs #9865
This middleware will be used by the admin api to authenticate and
authorize requests
* Update v2/admin to use authAdminApi middleware
refs #9865
This changes thh auth middleware to use the adminApi authenticate and
authorize middlewares underneath, it also renames the middleware to be
consistent with the naming of the api.
* Removed oauth specific endpoints from /v2/admin
refs #9865
These are not to be used in v2/admin
* Wired up the session controller to the admin api
refs #9865
These endpoints will be used by ghost admin to login, confirm logged in status and logout
refs #9326, refs #9866
**ATTENTION: This is the first iteration. Bugs are expected.**
Main Goals:
- add support for multiple API versions.
- do not touch v0.1 implementation
- do not break v0.1
## Problems with the existing v0.1 implementation
1. It tried to be generic and helpful, but it was a mixture of generic and explicit logic living in basically two files: utils.js and index.js.
2. Supporting multiple api versions means, you want to have as less as possible code per API version. With v0.1 it is impossible to reduce the API controller implementation.
----
This commit adds three things:
1. The tiny framework with well-defined API stages.
2. An example implementation of serving static pages via /pages for the content v2 API.
3. Unit tests to prove that the API framework works in general.
## API Stages
- validation
- input serialization
- permissions
- query
- output serialization
Each request should go through these stages. It is possible to disable stages, but it's not recommended.
The code for each stage will either live in a shared folder or in the API version itself. It depends how API specific the validation or serialization is. Depends on the use case.
We should add a specific API validator or serializer if the use case is API format specific.
We should put everything else to shared.
The goal is to add as much as possible into the shared API layer to reduce the logic per API version.
---
Serializers and validators can be added:
- for each request
- for specific controllers
- for specific actions
---
There is room for improvements/extensions:
1. Remove http header configuration from the API controller, because the API controller should not know about http - decouple.
2. Put permissions helpers into shared. I've just extracted and capsulated the permissions helpers into a single file for now. It had no priority. The focus was on the framework itself.
etc.
---
You can find more information about it in the API README.md (api/README.md)
- e.g. find more information about the structure
- e.g. example controllers
The docs are not perfect. We will improve the docs in the next two weeks.
---
Upcoming tasks:
- prepare test env to test multiple API versions
- copy over the controllers from v0.1 to v2
- adapt the v2 express app to use the v2 controllers
refs #9866
- Added test util method for api path based on version
- Updated all hardcoded v0.1 tests strings to use dynamic string from util method
- Updated hardcoded v0.1 tests using regex match to use string equal with new util method
no issue
- optimised only for web/ folder, because it has used very general namespaces
- the debug namespace must be specific, otherwise i run `DEBUG=ghost:api:*` and i get web debug logs and api folder debug logs
- we can come up with a new namespace system, but for now it must be explicit enough
Refs #9936
- Updated method to take single options param with version and admin instead of separate values
- Updated urlFor method to use the updated syntax
- Updated parent-app to use updated syntax
refs #9865
Note that this controller is the singular, that's because we plan to
make a session resource controller to be used with /sessions, wheras
this is on /session
Moved URL attributes logic from the model into API layer
refs #9866
- Moved URL related attribute calculation for posts, users, and tags into API layer
- Added test coverage for url attributes in tags/authors/primary_tags/primary_authors
refs #9866
- req.body is undefined if we don't use the body parser
- the content API only offers "fetch" endpoints, but if a component/module in Ghost relies on req.body being present, it can crash
- e.g. the authentication service checks for the existence of client_id + client_secret in req.query or req.body
- we could theoretically change it from `if (!req.body.client_id` to `if (req.body && !req.body.client_id)`, but that makes the code very hard to read + maintain
- we will use the body parser for the content API now
- req.body will be {}
no issue
- support promise and none promise tasks
- helpful if you create an array of operations and not all of the operations/tasks are async
- `response instanceof Promise` does not work for all cases e.g. some usages return a transaction/bookshelf chain
refs https://github.com/TryGhost/Ghost/issues/9865
- schema migrations
- adds `integrations` and `api_keys` tables
- inserts `integration` and `api_key` permissions and Administrator role relationships
- inserts `Admin Integration` role and permissions
- adds `Integration` model
- adds `ApiKey` model
- creates default secret if not given
- hardcodes associated role based on key type
- `admin` = `Admin API Client`
- `content` = no role
- updates `Role` model to use `bookshelf-relations` for auto cleanup of permission relationships on destroy
refs #9865
* This service handles the session store and exporting middleware to be
used for creating and managing sessions
* Updates the auth service index.js file in line with how we do things elsewhere
* After wrapping the exports in a getter, the usage of rewire had broken
the authenticate tests, this commit _removes_ rewire from the tests, calls `init` on
the models before the tests (needed because rewire isn't there) and also
cleans up the use of var.
refs #9866
- preparation for v2
- moved api/ to api/v0.1
- do export v0.1 straight from the api folder, we don't want to touch this right now
- that means currently if you require the api folder, we return v0.1 by default
- there were some direct requires of api files in the test env
- some of them use rewire
- for now, we just correct the require path to require api/v0.1/
- we touch the test env next week
**Docs about V2 design are coming soon!**
