Commit Graph

120 Commits

Author SHA1 Message Date
Kevin Ansfield
33fe21f888 Removed all clients and client_trusted_domains related code
no issue

- v0.1 is ☠️ so there's no longer any use of client auth
- removes all code related to `clients` and `client_trusted_domains`
- noops the "add backup client" migration in 1.7 because the referenced fixture no longer exists causing migrations and consequently all regression tests to fail
2019-09-12 15:09:49 +01:00
Nazar Gargol
c00c04df30 Removed unused translations 2019-09-12 14:49:56 +02:00
Naz Gargol
a9050f68ea
🔥 Removed V1 code/references in frontend helpers/meta layers (#11080)
no issue

- Removed deprecated 'blog' reference from frontend data. The alias (site->blog) stays till next version (v4) as it's not leaving much of technical debt but would ease the migration process for anybody still using it. 
- The follow up to this is substitute of all references to `options.data.blog` with `options.data.site` in "frontend"
- Fixed test utils helper to use `site` instead of `blog`
- Removed 0.1 flag checks in {{get}} helper
- Removed user aliasing from {{get}} helper
- Removed unused translation for {{get}} helper
- Added a note to excerpt changes in metadata for future reference
- Removed page alias used in description helper. The mix of page context with post object in the metadata was only possible in v0.1
- Changed mock in ghost_head helper to use v2
- Removed unneeded test for body class helper
2019-09-10 11:37:04 +02:00
Hannah Wolfe
9abffe4396 Added guard to asset helper for missing paths
refs #10496

- currently {{asset this/is/not/a.string}} would throw a 500 error
- this commit changes that to make it throw a sensible 400 + incorrect usage error
2019-09-09 13:02:45 +01:00
Paulo Barbosa
730e307d18 🐛Fixed generic 500 for bad key param in content API (#10977)
refs #10948

- Throws 400 when using multiple key query-values instead of a 500 error
2019-08-12 12:56:09 +01:00
Hannah Wolfe
b48fdaf1be Added {{link_class}} helper
- moved dynamic class logic out of {{link}} helper into shared utils
- both {{link}} and {{link_class}} use these utils
2019-08-05 12:12:05 +01:00
Aileen Nowak
d11fd4210b Updated docs api links to be version-less 2019-07-25 15:17:23 +08:00
Aileen Nowak
496f873ac4
Updated links to docs (#10941)
no issue
2019-07-22 18:17:50 +08:00
Vikas Potluri
c58236e549 🐛 Disallowed locked/suspended users from being made owner via the API (#10647)
- closes #10555
- Added a check to the user modal that the new owner is active 
- Had to refactor Owner->Author unit test (also renamed it)
  - Based on the first 2 lines, owner->editor change is attempted (hence the rename)
  - Since both stubs return a 'modal' with owner role which means owner->owner change is actually attempted
  - Now that there's a user status check, added the `status` property to the user receiving owernship
2019-04-16 10:30:29 +01:00
Fabien O'Carroll
4a22fcf73a Removed unused translations for apps service
no-issue
2019-04-16 11:05:33 +02:00
kirrg001
56deccb74d Added missing translation key: admin api kid
no issue

- found this by coincidence
2019-03-18 12:48:39 +01:00
Kevin Ansfield
0a846002f8 Renamed blog->site in error messages and welcome e-mail (#10586)
no issue

- general `blog` -> `site` wording switch
2019-03-11 15:25:21 +01:00
Kevin Ansfield
39edb7646e
Improved error message when attempting to use disabled v0.1 Public API (#10562)
no issue
- trying to use the v0.1 Public API when it was disabled led to a confusing error message, see https://forum.ghost.org/t/403-forbidden-error-on-postman-api-call/6017
- adds an explicit check for the Public API being enabled in the client authentication step and throws a useful error message if client auth is attempted when it's disabled
2019-03-05 10:41:07 +00:00
Fabien O'Carroll
4e6a6a24ac Updated Admin API key auth to require kid in header (#10538)
* Required kid be a header claim as according to spec

https://tools.ietf.org/html/rfc7515#section-4.1.4 (JWT is an extension of JWS)

* Updated error message for missing kid

* Fixed admin-api key unit tests

* Fixed regression and acceptance tests
2019-02-26 11:03:47 +07:00
Nazar Gargol
f558b58c89 Combined /images* endpoints into /images/upload
- refs #10438

- /images/upload now accepts all the image uploads and distinguishes their purpuse using new `purpose` form data field
2019-02-25 19:15:16 +07:00
Nazar Gargol
50ea7f0eff Added user friendly error messages to Admin API
refs #10438

- Adds new fields to errors returned from API:  help, code, and id
- Makes `message` more descriptive towards non technical users
2019-02-25 10:40:35 +07:00
Kevin Ansfield
288a38036b Improved error messages for failed authorization 2019-02-21 13:19:57 +07:00
Nazar Gargol
5f7c2b4d87 Improved error messaging returned from JSON Schema validations
refs #10438
2019-02-14 10:52:42 +00:00
Hannah Wolfe
426c122ed1 Updated messaging around {{get}} helper access
closes #10447

- Get helper message talks about the old API, but upgrading is the best way to solve the problem
- Had to create a way to add a custom message to a labs enabled helper to achieve this
2019-02-04 17:58:35 +00:00
kirrg001
7d05cbba1d Added notImplemented middleware for integrations
refs #9865
2019-01-30 14:15:12 +01:00
Rishabh Garg
8fd4b3f09f
Added new admin API for members (#10435)
no issue

- Added read and browse admin API for members
2019-01-30 17:06:09 +05:30
kirrg001
3f758c6a0a Protected against empty admin api key
refs #9865
2019-01-18 17:54:04 +01:00
Fabien O'Carroll
1c56221d80 Added API Key auth middleware to v2 Admin API (#10006)
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
2019-01-18 12:45:06 +00:00
Fabien O'Carroll
fc73cd71bb Updated permissions service to handle api keys (#9967)
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.
2019-01-18 11:17:11 +00:00
Hannah Wolfe
909f9012ed
Updated docs links to best equivalents (#10386)
* Updated docs links to best equivalents
   - Our documentation has been overhauled, this updates the all the old links sprinkled through Ghost
* Update integrity hash
2019-01-17 06:57:37 +00:00
Katharina Irrgang
9d7c3bd726
🐛 Fixed all known filter limitations (#10159)
refs #10105, closes #10108, closes https://github.com/TryGhost/Ghost/issues/9950, refs https://github.com/TryGhost/Ghost/issues/9923, refs https://github.com/TryGhost/Ghost/issues/9916, refs https://github.com/TryGhost/Ghost/issues/9574, refs https://github.com/TryGhost/Ghost/issues/6345, refs https://github.com/TryGhost/Ghost/issues/6309, refs https://github.com/TryGhost/Ghost/issues/6158, refs https://github.com/TryGhost/GQL/issues/16

- removed GQL dependency
- replaced GQL with our brand new NQL implementation
- fixed all known filter limitations
- GQL suffered from some underlying filter bugs, which NQL tried to fix
- the bugs were mostly in how we query the database for relation filtering
- the underlying problem was caused by a too simple implementation of querying the relations
- mongo-knex has implemented a more robust and complex filtering mechanism for relations
- replaced logic in our bookshelf filter plugin
- we pass the custom, default and override filters from Ghost to NQL, which then are getting parsed and merged into a mongo JSON object. The mongo JSON is getting attached by mongo-knex.

NQL: https://github.com/NexesJS/NQL
mongo-knex: https://github.com/NexesJS/mongo-knex
2018-12-11 11:53:40 +01:00
Katharina Irrgang
ff6bf5f318 Renamed /users to /authors for Content API V2 (#10096)
refs #10061

- Made /authors endpoint available in Content API V2
2018-11-07 15:29:37 +01:00
Kevin Ansfield
71f0c08a34
Added edit webhook route to v2 Admin API (#10033)
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
2018-10-19 18:35:55 +01:00
kirrg001
cbf2817e39 Added missing read pages endpoint
refs #9866

- the endpoints were missing
- the site app needs pages.read for v2
2018-10-18 19:41:07 +02:00
Fabien O'Carroll
17feb14e4a Added HTTP BREAD for integrations resource (#9985)
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
2018-10-18 14:03:56 +01:00
kirrg001
15a8951bc7 Respected hasUserPermissions & hasAppPermissions in invite model
no issue

- the permission service expects from the permissible function to respect the input values
  - hasUserPermissions
  - hasAppPermissions
2018-10-16 18:00:05 +02:00
Fabien O'Carroll
3db102a776
Added API Key auth middleware to v2 content API (#10005)
* 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
2018-10-15 16:23:34 +07:00
Fabien O'Carroll
f9c8f2d0da
Included expected and actual origin in csrf error (#9974)
refs #9865
refs #9972

The previous error message did not have enough information for a user to
self diagnose issues on their blog.
2018-10-10 14:36:45 +07:00
Fabien O'Carroll
150c0d4de7
Added more detail to unknown origin error message (#9973)
refs #9865

The previous error message didn't have much in the way of helping a user
fix or diagnose the problem.
2018-10-10 09:27:09 +07:00
Fabien O'Carroll
cb0c5dc582
Session auth service (#9910)
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.
2018-10-02 15:35:23 +07:00
Rishabh Garg
39485d17c0 Added new endpoint to upload square profile images with dimension validation (#9862)
refs #8576

- adds new API endpoint `/uploads/profile-image` for uploading profile images
- new validation which fails with error message if uploaded image is not square
- Renamed getImageSizeFromFilePath to getImageSizeFromStoragePath, because it's more explicit
- Add new getImageSizeFromPath method, which is used in the new dimensions middleware
- Ensure we use the sharp middleware to auto-resize the uploaded profile pictures
- Ensure the new route get's added to v2

While this makes sure all future profile images uploaded are square, this doesn’t affect any existing non-square profile image. Needs more thought on how to handle existing non-square profile images for the purpose of making theming easier in future.
2018-09-24 21:42:58 +02:00
kirrg001
dd1e8f7f90 Changed maintenance messages
no issue
2018-08-16 12:13:24 +02:00
kirrg001
c40454f23c Added ability to upload/reload routes.yaml
refs #9744

- added two new endpoints to upload/download routes.yaml
- reload site express app on successful/valid upload
- reload url service on sucessfuly upload
- force clear cache of pages
- ensure we keep a backup of the routes.yaml file
- this feature was mostly tested manually
- @TODO: i have to write unit tests - will do later
- @TODO: do a memory test to ensure we haven't introduced any memory leaks with this feature
2018-08-16 12:13:24 +02:00
kirrg001
d518f23b48 Updated docs links
refs #9742

- rebase against master updated some docs links again
- go over code base again and double check that all docs links are correct
- 2.0 will become the latest version on our readme pages
2018-08-16 12:13:24 +02:00
kirrg001
132df78940 Updated docs links
refs #9742

- Ghost 2.0 is coming
- all doc links in 1.0 must use concrete links e.g. docs.ghost.org/v1 or themes.ghost.org/v1.23.0/
- if we release Ghost 2.0, docs.ghost.org will show 2.0 docs
2018-07-20 23:49:16 +02:00
Kevin Ansfield
ca20f3a6b0 Added /oembed API endpoint
refs https://github.com/TryGhost/Ghost/issues/9623
- add `oembed-parser` module for checking provider availability for a url and fetching data from the provider
  - require it in the `overrides.js` file before the general Promise override so that the `promise-wrt` sub-dependency doesn't attempt to extend the Bluebird promise implementation
- add `/oembed` authenticated endpoint
  - takes `?url=` query parameter to match against known providers
  - adds safeguard against oembed-parser's providers list not recognising http+https and www+non-www
  - responds with `ValidationError` if no provider is found
  - responds with oembed response from matched provider's oembed endpoint if match is found
2018-06-12 16:18:01 +01:00
Hannah Wolfe
0dd619b688
Improved error message for URL Service 503s
- simplify language + consistency with other similar messages
2018-06-11 17:01:07 +01:00
Katharina Irrgang
b392d1925a
Dynamic Routing Beta (#9596)
refs #9601

### Dynamic Routing

This is the beta version of dynamic routing. 

- we had a initial implementation of "channels" available in the codebase
- we have removed and moved this implementation 
- there is now a centralised place for dynamic routing - server/services/routing
- each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts
- keep as much as possible logic of routing helpers, middlewares and controllers
- ensure test coverage
- connect all the things together
  - yaml file + validation
  - routing + routers
  - url service
  - sitemaps
  - url access
- deeper implementation of yaml validations
  - e.g. hard require slashes
- ensure routing hierarchy/order
  - e.g. you enable the subscriber app
  - you have a custom static page, which lives under the same slug /subscribe
  - static pages are stronger than apps
  - e.g. the first collection owns the post it has filtered
  - a post cannot live in two collections
- ensure apps are still working and hook into the routers layer (or better said: and register in the routing service)
- put as much as possible comments to the code base for better understanding
- ensure a clean debug log
- ensure we can unmount routes
  - e.g. you have a collection permalink of /:slug/ represented by {globals.permalink}
  - and you change the permalink in the admin to dated permalink
  - the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/
  - unmount without server restart, yey
- ensure we are backwards compatible
  - e.g. render home.hbs for collection index if collection route is /
  - ensure you can access your configured permalink from the settings table with {globals.permalink}

### Render 503 if url service did not finish

- return 503 if the url service has not finished generating the resource urls

### Rewrite sitemaps

- we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime
- we generate all urls on bootstrap
- the sitemaps service will consume created resource and router urls
- these urls will be shown on the xml pages
- we listen on url events
- we listen on router events
- we no longer have to fetch the resources, which is nice
  - the urlservice pre-fetches resources and emits their urls
- the urlservice is the only component who knows which urls are valid
- i made some ES6 adaptions
- we keep the caching logic -> only regenerate xml if there is a change
- updated tests
- checked test coverage (100%)

### Re-work usage of Url utility

- replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId`
  - only for resources e.g. post, author, tag
- this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime
- adapt url utility
- adapt tests
2018-06-05 19:02:20 +02:00
kirrg001
e43bdad818 Fixed broken i18n keys
refs #9519

- discovered by https://github.com/TryGhost/Ghost/issues/9519#issuecomment-374891164
2018-04-18 15:05:20 +02:00
Aileen Nowak
63642fd8ad YAML settings loader and parser
closes #9528

These code changes introduce a YAML parser which will load and parse YAML files from the `/content/settings` directory. There are three major parts involved:

1. `ensure-settings.js`: this fn takes care that on bootstrap, the supported files are present in the `/content/settings` directory. If the files are not present, they get copied back from our default files. The default files to copy from are located in `core/server/services/settings`.

2. `loader.js`: the settings loader reads the requested `yaml` file from the disk and passes it to the yaml parser, which returns a `json` object of the file. The settings loader throws an error, if the file is not accessible, e. g. because of permission errors.

3. `yaml-parser`: gets passed a `yaml` file and returns a `json` object. If the file is not parseable, it returns a clear error that contains the information, what and where the parsing error occurred (e. g. line number and reason).

- added a `get()` fn to settings services, that returns the settings object that's asked for. e. g. `settings.get('routes').then(()...` will return the `routes` settings.
- added a `getAll()` fn to settings services, that returns all available settings in an object. The object looks like: `{routes: {routes: {}, collections: {}, resources: {}}, globals: {value: {}}`, assuming that we have to supported settings `routes` and `globals`.

Further additions:
- config `contentPath` for `settings`
- config overrides for default `yaml` files location in `/core/server/services/settings`

**Important**: These code changes are in preparation for Dynamic Routing and not yet used. The process of copying the supported `yaml` files (in this first step, the `routes.yaml` file) is not yet activated.
2018-04-15 19:40:22 +02:00
Katharina Irrgang
40d0a745df Multiple authors (#9426)
no issue

This PR adds the server side logic for multiple authors. This adds the ability to add multiple authors per post. We keep and support single authors (maybe till the next major - this is still in discussion)

### key notes

- `authors` are not fetched by default, only if we need them
- the migration script iterates over all posts and figures out if an author_id is valid and exists (in master we can add invalid author_id's) and then adds the relation (falls back to owner if invalid)
- ~~i had to push a fork of bookshelf to npm because we currently can't bump bookshelf + the two bugs i discovered are anyway not yet merged (https://github.com/kirrg001/bookshelf/commits/master)~~ replaced by new bookshelf release
- the implementation of single & multiple authors lives in a single place (introduction of a new concept: model relation)
- if you destroy an author, we keep the behaviour for now -> remove all posts where the primary author id matches. furthermore, remove all relations in posts_authors (e.g. secondary author)
- we make re-use of the `excludeAttrs` concept which was invented in the contributors PR (to protect editing authors as author/contributor role) -> i've added a clear todo that we need a logic to make a diff of the target relation -> both for tags and authors
- `authors` helper available (same as `tags` helper)
- `primary_author` computed field available
- `primary_author` functionality available (same as `primary_tag` e.g. permalinks, prev/next helper etc)
2018-03-27 15:16:15 +01:00
kirrg001
e01b61dcf4 Proper error handling for permissible implementations
no issue

- currently if you would like to edit a resource (e.g. post) and you pass an invalid model id, the following happens
  - permission check calls `Post.permissible`
  - the Post could not find the post, but ignored it and returned `userPermissions:true`
  - then the model layer is queried again and figured out that the post does not exist
- A: there is no need to query the model twice
- B: we needed proper error handling for post and role model
2018-02-21 16:59:48 +01:00
Katharina Irrgang
a274d61a8c Removed html usage in error messages (#9444)
no issue

- all of the error message keys were unused
- the only html anchor i found was for mail, but this doesn't change anything, because the admin does only show the message and not the context at the moment
2018-02-07 09:35:48 +01:00
Katharina Irrgang
5b77f052d9
Update Notification improvements (#9123)
closes #5071

- Remove hardcoded notification in admin controller
  - NOTE: update check notifications are no longer blocking the admin rendering
  - this is one of the most import changes
  - we remove the hardcoded release message
  - we also remove adding a notification manually in here, because this will work differently from now on
    -> you receive a notification (release or custom) in the update check module and this module adds the notification as is to our database

- Change default core settings keys
  - remove displayUpdateNotification
    -> this was used to store the release version number send from the UCS
    -> based on this value, Ghost creates a notification container with self defined values
    -> not needed anymore

- rename seenNotifications to notifications
  -> the new notifications key will hold both
     1. the notification from the USC
     2. the information about if a notification was seen or not
  - this key hold only one release notification
  - and n custom notifications

- Update Check Module: Request to the USC depends on the privacy configuration
  - useUpdateCheck: true -> does a checkin in the USC (exposes data)
  - useUpdateCheck: false -> does only a GET query to the USC (does not expose any data)
  - make the request handling dynamic, so it depends on the flag
  - add an extra logic to be able to define a custom USC endpoint (helpful for testing)
  - add an extra logic to be able to force the request to the service (helpful for testing)

- Update check module: re-work condition when a check should happen
  - only if the env is not correct
  - remove deprecated config.updateCheck
  - remove isPrivacyDisabled check (handled differently now, explained in last commit)

- Update check module: remove `showUpdateNotification` and readability
  - showUpdateNotification was used in the admin controller to fetch the latest release version number from the db
  - no need to check against semver in general, the USC takes care of that (no need to double check)
  - improve readability of `nextUpdateCheck` condition

- Update check module: refactor `updateCheckResponse`
  - remove db call to displayUpdateNotification, not used anymore
  - support receiving multiple custom notifications
  - support custom notification groups
  - the default group is `all` - this will always be consumed
  - groups can be extended via config e.g. `notificationGroups: ['migration']`

- Update check module: refactor createCustomNotification helper
  - get rid of taking over notification duplication handling (this is not the task of the update check module)
  - ensure we have good fallback values for non present attributes in a notification
  - get rid of semver check (happens in the USC) - could be reconsidered later if LTS is gone

- Refactor notification API
  - reason: get rid of in process notification store
    -> this was an object hold in process
    -> everything get's lost after restart
    -> not helpful anymore, because imagine the following case
      -> you get a notification
      -> you store it in process
      -> you mark this notification as seen
      -> you restart Ghost, you will receive the same notification on the next check again
      -> because we are no longer have a separate seen notifications object
  - use database settings key `notification` instead
  - refactor all api endpoints to support reading and storing into the `notifications` object
  - most important: notification deletion happens via a `seen` property (the notification get's physically deleted 3 month automatically)
    -> we have to remember a seen property, because otherwise you don't know which notification was already received/seen

- Add listener to remove seen notifications automatically after 3 month
  - i just decided for 3 month (we can decrease?)
  - at the end it doesn't really matter, as long as the windows is not tooooo short
  - listen on updates for the notifications settings
  - check if notification was seen and is older than 3 month
  - ignore release notification

- Updated our privacy document
- Updated docs.ghost.org for privacy config behaviour
- contains a migration script to remove old settings keys
2018-01-09 15:20:00 +01:00
juan-g
4cca2353e0 consistency change for english translation keys: use camel case (#9347)
no issue

- required for #8437 
- one instance of hyphenated key changed; the rest of keys in file
_core/server/translations/en.json_ are already camelCase
- also converted `common.i18n.t()` calls to this key in file
_core/server/update-check.js_
- this allows to simplify i18n to an unified use of `jsonpath`
2017-12-18 15:47:55 +01:00