no-issue
* Added InternalServerError to resizeImage
* Added a redirect to original image if sharp is missing
* Improved naming - safeMethod -> method
* Updated process method to follow same sharp check pattern
* Refactor safety wrapper into makeSafe function
* Moved generic manipulation error to makeSafe function
* Refactored unsafeProcess to use unsafeResizeImage
* Removed CRAZY catch
refs #10181
* Added initial handleImageSizes middleware
* Implemented saveRaw method on local file storage
* Wired up handleImageSizes middleware
* Implemented delete for LocalFileStorage
* Removed delete method from theme Storage class
* Deleted sizes directory when theme is activated
* Ensured that smaller images are not enlarged
* Renamed sizes -> size
* Exited middleware as early as possible
* Called getStorage as late as possible
* Updated image sizes middleware to handle dimension paths
* Revert "Deleted sizes directory when theme is activated"
This reverts commit 9204dfcc73a6a79d597dbf23651817bcbfc59991.
* Revert "Removed delete method from theme Storage class"
This reverts commit b45fdb405a05faeaf4bd87e977c4ac64ff96b057.
* Revert "Implemented delete for LocalFileStorage"
This reverts commit a587cd6bae45b68a293b2d5cfd9b7705a29e7bfa.
* Fixed typo
Co-Authored-By: allouis <fabien@allou.is>
* Redirected to original image if no image_sizes config
* Refactored redirection because rule of three
* Updated comments
* Added rubbish tests
* Added @TODO comment for handleImageSizes tests
* Added safeResizeImage method to image manipulator
* Used image manipulator lib in image_size middleware
* Updated auth service members middleware
refs #10213
* Wired up members api router to the ghost api endpoints
refs #10213
* Created members app for the static pages
refs #10213
* Wired up the members app
refs #10213
no-issue
When trying to use /api/v2/content from a different domain, the requests
were failing with CORS errors. This doesn't use the shared cors middleware,
because it should be open to all hosts, and not locked down via our
whitelist or trusted domains.
closes#10226
- Middleware emits site-changed event used to trigger webhook, was configured to v2 admin api only.
- Change allows all versions of api to emit event in case of cache invalidation
* Added updateLastSeen method to user model
refs #10138
* Refactor codebase to use user.updateLastSeen
refs #10138
This is to ensure all updates go via the same method, meaning any
specific logic can be handled in one place, it also helps with grepping
the codebase to find where this occurs
* Created updateUserLastSeen middleware for v2 admin
refs #10138
This is intended to be used with the v2 admin api and _possibly_ the
content api, to give us an accruate report on thelast time a user access
a ghost instance.
* Wired updateUserLastSeen up to v2 Admin API
closes#10138
* Fixed broken test for v2 admin api
no-issue
This test was broken because it was incorrectly testing for a method to
be called exactly once - this was irrelevant to the functionality being
tested for.
* Updated user check method to set status to active
no-issue
* Debounced the updateUserLastSeen middlware an hour
no-issue
* Resolved some PR comments
no-issue
This is because the Content API will eventually be accessed not just
from Content API keys. The addition of a Content API specific
authorization middleware is because:
1. content api should not authorize based on req.user
2. content api will need separate authorization than admin api
no issue
- webhooks UI requires the ability to edit webhooks
- added `edit` permission for `webhook`
- added `edit` method to v2 webhook controller
- added `PUT /webhooks/:id` route to v2 Admin API routes
refs #9942
* Added new middleware to trigger events
* Refactored webhooks service
- added new trigger service, moved listen service to its own file
- started listening to new site.changed event
- cleaned up trigger service to work with new webhook fields
- cleaned up tests
- removed redundant trigger method in v0.1 controller
refs #9865
* Added generic messaging for resource not found
* Ensured integration model uses transaction for writes
* Created POST /integrations endpoint
* Created GET /integrations/:id endpoint
* Created GET /integrations endpoint
* Created PUT /integrations/:id endpoint
* Created DELETE /integrations/:id endpoint
no-issue
- Added spam prevention to POST /session
- This blocks repeated requests the the /session endpoint preventing brute
force password attacks
- Updated session controller to reset brute middleware
- This updates the session controller to reset the brute force protection
on a successful login. This is required so that a user is not locked out
forever :o!!
refs #9866
- Refactored overrides config to include direct version configs(v0.1, v2), supported versions map to direct version
- Refactored `getApiPath` to handle direct versions as well as mappings of supported version
no-issue
The content API only supports GET requests so has no need for cors
middleware on OPTIONS. This also removes the router.del helper as it's
not used
* Added API Key auth middleware to v2 content API
refs #9865
- add `auth.authenticate.authenticateContentApiKey` middleware
- accepts `?key=` query param, sets `req.api_key` if it's a known Content API key
- add `requiresAuthorizedUserOrApiKey` authorization middleware
- passes if either `req.user` or `req.api_key` exists
- update `authenticatePublic` middleware stack for v2 content routes
* Fixed functional content api tests
no-issue
This fixes the functional content api tests so they use the content api
auth.
* Fixed context check and removed skip
* Updated cors middleware for content api
* Removed client_id from frame.context
no-issue
The v2 api doesn't have a notion of clients as we do not use oauth for it
* Fixed tests for posts input serializer
refs #9866
- Added logic ensuring page filter is always set to false in posts endpoint for Content API
- Added functional tests to pages and posts
- Added absolute_url logic in pages controller
- Added slugs controller to v2 API
- Added slugs tests to v2 API
- Updated generic validation error message in shared validator to return validation error with sub-message
* 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
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 #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 {}
refs #9866
- added api version config to overrides, which makes it possible to have a centralized api versioning configuration
- the next PR will use this config in the web folder
- make api url generation in url service flexible and dynamic
- remove hardcoded API_PATH
- updated all places which used `urlFor('api'..)` -> we now ask for explicit api version
