2017-11-21 18:43:14 +03:00
|
|
|
// # Webhooks API
|
|
|
|
// RESTful API for creating webhooks
|
|
|
|
// also known as "REST Hooks", see http://resthooks.org
|
|
|
|
var Promise = require('bluebird'),
|
|
|
|
_ = require('lodash'),
|
2017-12-14 00:20:02 +03:00
|
|
|
pipeline = require('../lib/promise/pipeline'),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils = require('./utils'),
|
2017-11-21 18:43:14 +03:00
|
|
|
models = require('../models'),
|
2017-12-12 00:47:46 +03:00
|
|
|
common = require('../lib/common'),
|
2017-12-14 13:00:34 +03:00
|
|
|
request = require('../lib/request'),
|
2017-11-21 18:43:14 +03:00
|
|
|
docName = 'webhooks',
|
|
|
|
webhooks;
|
|
|
|
|
|
|
|
function makeRequest(webhook, payload, options) {
|
|
|
|
var event = webhook.get('event'),
|
|
|
|
targetUrl = webhook.get('target_url'),
|
|
|
|
webhookId = webhook.get('id'),
|
2017-12-14 13:00:34 +03:00
|
|
|
reqPayload = JSON.stringify(payload);
|
2017-11-21 18:43:14 +03:00
|
|
|
|
2017-12-12 00:47:46 +03:00
|
|
|
common.logging.info('webhook.trigger', event, targetUrl);
|
2017-11-21 18:43:14 +03:00
|
|
|
|
2017-12-14 13:00:34 +03:00
|
|
|
request(targetUrl, {
|
|
|
|
body: reqPayload,
|
|
|
|
headers: {
|
|
|
|
'Content-Length': Buffer.byteLength(reqPayload),
|
|
|
|
'Content-Type': 'application/json'
|
|
|
|
},
|
|
|
|
timeout: 2 * 1000,
|
|
|
|
retries: 5
|
|
|
|
}).catch(function (err) {
|
2017-11-21 18:43:14 +03:00
|
|
|
// when a webhook responds with a 410 Gone response we should remove the hook
|
2017-12-14 13:00:34 +03:00
|
|
|
if (err.statusCode === 410) {
|
2017-12-12 00:47:46 +03:00
|
|
|
common.logging.info('webhook.destroy (410 response)', event, targetUrl);
|
2017-11-21 18:43:14 +03:00
|
|
|
return models.Webhook.destroy({id: webhookId}, options);
|
|
|
|
}
|
|
|
|
|
2017-12-12 00:47:46 +03:00
|
|
|
common.logging.error(new common.errors.GhostError({
|
2017-11-21 18:43:14 +03:00
|
|
|
err: err,
|
|
|
|
context: {
|
|
|
|
id: webhookId,
|
|
|
|
event: event,
|
|
|
|
target_url: targetUrl,
|
|
|
|
payload: payload
|
|
|
|
}
|
|
|
|
}));
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
function makeRequests(webhooksCollection, payload, options) {
|
|
|
|
_.each(webhooksCollection.models, function (webhook) {
|
|
|
|
makeRequest(webhook, payload, options);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ## Webhook API Methods
|
|
|
|
*
|
2017-12-14 16:13:40 +03:00
|
|
|
* **See:** [API Methods](constants.js.html#api%20methods)
|
2017-11-21 18:43:14 +03:00
|
|
|
*/
|
|
|
|
webhooks = {
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Add
|
|
|
|
* @param {Webhook} object the webhook to create
|
|
|
|
* @returns {Promise(Webhook)} newly created Webhook
|
|
|
|
*/
|
|
|
|
add: function add(object, options) {
|
|
|
|
var tasks;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Model Query
|
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function doQuery(options) {
|
|
|
|
return models.Webhook.getByEventAndTarget(options.data.webhooks[0].event, options.data.webhooks[0].target_url, _.omit(options, ['data']))
|
|
|
|
.then(function (webhook) {
|
|
|
|
if (webhook) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({message: common.i18n.t('errors.api.webhooks.webhookAlreadyExists')}));
|
2017-11-21 18:43:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return models.Webhook.add(options.data.webhooks[0], _.omit(options, ['data']));
|
|
|
|
})
|
|
|
|
.then(function onModelResponse(model) {
|
|
|
|
return {
|
|
|
|
webhooks: [model.toJSON(options)]
|
|
|
|
};
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName),
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
localUtils.convertOptions(),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.handlePermissions(docName, 'add'),
|
2017-11-21 18:43:14 +03:00
|
|
|
doQuery
|
|
|
|
];
|
|
|
|
|
|
|
|
// Pipeline calls each task passing the result of one to be the arguments for the next
|
|
|
|
return pipeline(tasks, object, options);
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ## Destroy
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
* @param {{id, context}} options
|
|
|
|
* @return {Promise}
|
|
|
|
*/
|
|
|
|
destroy: function destroy(options) {
|
|
|
|
var tasks;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Delete Webhook
|
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
*/
|
|
|
|
function doQuery(options) {
|
|
|
|
return models.Webhook.destroy(options).return(null);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName, {opts: localUtils.idDefaultOptions}),
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
localUtils.convertOptions(),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.handlePermissions(docName, 'destroy'),
|
2017-11-21 18:43:14 +03:00
|
|
|
doQuery
|
|
|
|
];
|
|
|
|
|
|
|
|
// Pipeline calls each task passing the result of one to be the arguments for the next
|
|
|
|
return pipeline(tasks, options);
|
|
|
|
},
|
|
|
|
|
|
|
|
trigger: function trigger(event, payload, options) {
|
|
|
|
var tasks;
|
|
|
|
|
|
|
|
function doQuery(options) {
|
|
|
|
return models.Webhook.findAllByEvent(event, options);
|
|
|
|
}
|
|
|
|
|
|
|
|
tasks = [
|
|
|
|
doQuery,
|
|
|
|
_.partialRight(makeRequests, payload, options)
|
|
|
|
];
|
|
|
|
|
|
|
|
return pipeline(tasks, options);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
module.exports = webhooks;
|