2018-10-05 16:38:14 +03:00
|
|
|
const Promise = require('bluebird');
|
|
|
|
const _ = require('lodash');
|
|
|
|
const common = require('../lib/common');
|
|
|
|
const constants = require('../lib/constants');
|
|
|
|
const security = require('../lib/security');
|
|
|
|
const settingsCache = require('../services/settings/cache');
|
|
|
|
const ghostBookshelf = require('./base');
|
2017-12-14 16:13:40 +03:00
|
|
|
|
|
|
|
let Invite,
|
2016-09-21 17:48:14 +03:00
|
|
|
Invites;
|
|
|
|
|
|
|
|
Invite = ghostBookshelf.Model.extend({
|
|
|
|
tableName: 'invites',
|
|
|
|
|
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
|
|
|
toJSON: function (unfilteredOptions) {
|
|
|
|
var options = Invite.filterOptions(unfilteredOptions, 'toJSON'),
|
|
|
|
attrs = ghostBookshelf.Model.prototype.toJSON.call(this, options);
|
2016-09-21 17:48:14 +03:00
|
|
|
|
|
|
|
delete attrs.token;
|
|
|
|
return attrs;
|
|
|
|
}
|
|
|
|
}, {
|
|
|
|
orderDefaultOptions: function orderDefaultOptions() {
|
|
|
|
return {};
|
|
|
|
},
|
|
|
|
|
2018-04-25 12:56:45 +03:00
|
|
|
add: function add(data, unfilteredOptions) {
|
|
|
|
const options = Invite.filterOptions(unfilteredOptions, 'add');
|
|
|
|
data = data || {};
|
2016-09-21 17:48:14 +03:00
|
|
|
|
2018-04-25 12:56:45 +03:00
|
|
|
if (!options.context || !options.context.internal) {
|
|
|
|
data.status = 'pending';
|
|
|
|
}
|
2016-09-21 17:48:14 +03:00
|
|
|
|
2018-04-25 12:56:45 +03:00
|
|
|
data.expires = Date.now() + constants.ONE_WEEK_MS;
|
2018-06-22 21:28:01 +03:00
|
|
|
data.token = security.tokens.generateFromEmail({
|
2018-04-25 12:56:45 +03:00
|
|
|
email: data.email,
|
|
|
|
expires: data.expires,
|
|
|
|
secret: settingsCache.get('db_hash')
|
|
|
|
});
|
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
|
|
|
|
2016-11-16 12:33:44 +03:00
|
|
|
return ghostBookshelf.Model.add.call(this, data, options);
|
2018-10-05 16:38:14 +03:00
|
|
|
},
|
|
|
|
|
2019-01-18 15:39:53 +03:00
|
|
|
permissible(inviteModel, action, context, unsafeAttrs, loadedPermissions, hasUserPermission, hasAppPermission, hasApiKeyPermission) {
|
2018-10-05 16:38:14 +03:00
|
|
|
const isAdd = (action === 'add');
|
|
|
|
|
|
|
|
if (!isAdd) {
|
2019-01-18 15:39:53 +03:00
|
|
|
if (hasUserPermission && hasAppPermission && hasApiKeyPermission) {
|
2018-10-16 19:00:05 +03:00
|
|
|
return Promise.resolve();
|
|
|
|
}
|
|
|
|
|
|
|
|
return Promise.reject(new common.errors.NoPermissionError({
|
|
|
|
message: common.i18n.t('errors.models.invite.notEnoughPermission')
|
|
|
|
}));
|
2018-10-05 16:38:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// CASE: make sure user is allowed to add a user with this role
|
|
|
|
return ghostBookshelf.model('Role')
|
|
|
|
.findOne({id: unsafeAttrs.role_id})
|
|
|
|
.then((roleToInvite) => {
|
|
|
|
if (!roleToInvite) {
|
|
|
|
return Promise.reject(new common.errors.NotFoundError({
|
|
|
|
message: common.i18n.t('errors.api.invites.roleNotFound')
|
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (roleToInvite.get('name') === 'Owner') {
|
|
|
|
return Promise.reject(new common.errors.NoPermissionError({
|
|
|
|
message: common.i18n.t('errors.api.invites.notAllowedToInviteOwner')
|
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
let allowed = [];
|
|
|
|
|
|
|
|
if (_.some(loadedPermissions.user.roles, {name: 'Owner'}) ||
|
|
|
|
_.some(loadedPermissions.user.roles, {name: 'Administrator'})) {
|
|
|
|
allowed = ['Administrator', 'Editor', 'Author', 'Contributor'];
|
|
|
|
} else if (_.some(loadedPermissions.user.roles, {name: 'Editor'})) {
|
|
|
|
allowed = ['Author', 'Contributor'];
|
|
|
|
}
|
|
|
|
|
|
|
|
if (allowed.indexOf(roleToInvite.get('name')) === -1) {
|
|
|
|
throw new common.errors.NoPermissionError({
|
|
|
|
message: common.i18n.t('errors.api.invites.notAllowedToInvite')
|
|
|
|
});
|
|
|
|
}
|
2018-10-16 19:00:05 +03:00
|
|
|
|
2019-01-18 15:39:53 +03:00
|
|
|
if (hasUserPermission && hasAppPermission && hasApiKeyPermission) {
|
2018-10-16 19:00:05 +03:00
|
|
|
return Promise.resolve();
|
|
|
|
}
|
|
|
|
|
|
|
|
return Promise.reject(new common.errors.NoPermissionError({
|
|
|
|
message: common.i18n.t('errors.models.invite.notEnoughPermission')
|
|
|
|
}));
|
2018-10-05 16:38:14 +03:00
|
|
|
});
|
2016-09-21 17:48:14 +03:00
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
Invites = ghostBookshelf.Collection.extend({
|
|
|
|
model: Invite
|
|
|
|
});
|
|
|
|
|
|
|
|
module.exports = {
|
|
|
|
Invite: ghostBookshelf.model('Invite', Invite),
|
|
|
|
Invites: ghostBookshelf.collection('Invites', Invites)
|
|
|
|
};
|