Ghost/core/server/models/invite.js

108 lines
3.7 KiB
JavaScript
Raw Normal View History

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');
let Invite,
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);
delete attrs.token;
return attrs;
}
}, {
orderDefaultOptions: function orderDefaultOptions() {
return {};
},
add: function add(data, unfilteredOptions) {
const options = Invite.filterOptions(unfilteredOptions, 'add');
data = data || {};
if (!options.context || !options.context.internal) {
data.status = 'pending';
}
data.expires = Date.now() + constants.ONE_WEEK_MS;
data.token = security.tokens.generateFromEmail({
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
return ghostBookshelf.Model.add.call(this, data, options);
},
permissible(inviteModel, action, context, unsafeAttrs, loadedPermissions, hasUserPermission, hasAppPermission, hasApiKeyPermission) {
const isAdd = (action === 'add');
if (!isAdd) {
if (hasUserPermission && hasAppPermission && hasApiKeyPermission) {
return Promise.resolve();
}
return Promise.reject(new common.errors.NoPermissionError({
message: common.i18n.t('errors.models.invite.notEnoughPermission')
}));
}
// 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')
});
}
if (hasUserPermission && hasAppPermission && hasApiKeyPermission) {
return Promise.resolve();
}
return Promise.reject(new common.errors.NoPermissionError({
message: common.i18n.t('errors.models.invite.notEnoughPermission')
}));
});
}
});
Invites = ghostBookshelf.Collection.extend({
model: Invite
});
module.exports = {
Invite: ghostBookshelf.model('Invite', Invite),
Invites: ghostBookshelf.collection('Invites', Invites)
};