Ghost/core/server/models/settings.js

244 lines
8.3 KiB
JavaScript
Raw Normal View History

const Promise = require('bluebird'),
_ = require('lodash'),
uuid = require('uuid'),
crypto = require('crypto'),
keypair = require('keypair'),
🎨 ⏱ Cleanup / optimise the server.init() function (#7985) refs #2182 * 🔥 Remove unused options from server init - this is left over from old code and is now unused * 🎨 Move knex-migrator check to db health - Move complex check function into own module - Call module from server/index.js - This just improves the readability of server/index.js * 🔥 Remove old comments - These comments all make no sense now! * 🎨 ⏱ Move model init out of promise chain - Model.init() does not return a promise - Therefore, we can move it to the top of the init function, outside of the promise change - This should be a minor optimisation, and again improves readability /clarity of what's happening * ✨ ⁉️ Move DBHash init / first run to Settings model - this structure is left over from when we had code we executed on the first run of Ghost - the implementation used the API to initialise one setting before populateDefaults is called - this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work - the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults() - it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!) - perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁 * ⏱ Optimise require order so config is first - the first require to config will cause the files to be read etc - this ensures that it happens early, and isn't confusingly timed as part of loading a different module * 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
ghostBookshelf = require('./base'),
common = require('../lib/common'),
validation = require('../data/validation'),
internalContext = {context: {internal: true}};
🎨 ⏱ Cleanup / optimise the server.init() function (#7985) refs #2182 * 🔥 Remove unused options from server init - this is left over from old code and is now unused * 🎨 Move knex-migrator check to db health - Move complex check function into own module - Call module from server/index.js - This just improves the readability of server/index.js * 🔥 Remove old comments - These comments all make no sense now! * 🎨 ⏱ Move model init out of promise chain - Model.init() does not return a promise - Therefore, we can move it to the top of the init function, outside of the promise change - This should be a minor optimisation, and again improves readability /clarity of what's happening * ✨ ⁉️ Move DBHash init / first run to Settings model - this structure is left over from when we had code we executed on the first run of Ghost - the implementation used the API to initialise one setting before populateDefaults is called - this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work - the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults() - it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!) - perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁 * ⏱ Optimise require order so config is first - the first require to config will cause the files to be read etc - this ensures that it happens early, and isn't confusingly timed as part of loading a different module * 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
let Settings, defaultSettings;
const doBlock = fn => fn();
const getMembersKey = doBlock(() => {
let UNO_KEYPAIRINO;
return function getMembersKey(type) {
if (!UNO_KEYPAIRINO) {
UNO_KEYPAIRINO = keypair({bits: 1024});
}
return UNO_KEYPAIRINO[type];
};
});
// For neatness, the defaults file is split into categories.
// It's much easier for us to work with it as a single level
// instead of iterating those categories every time
function parseDefaultSettings() {
var defaultSettingsInCategories = require('../data/schema/').defaultSettings,
🎨 ⏱ Cleanup / optimise the server.init() function (#7985) refs #2182 * 🔥 Remove unused options from server init - this is left over from old code and is now unused * 🎨 Move knex-migrator check to db health - Move complex check function into own module - Call module from server/index.js - This just improves the readability of server/index.js * 🔥 Remove old comments - These comments all make no sense now! * 🎨 ⏱ Move model init out of promise chain - Model.init() does not return a promise - Therefore, we can move it to the top of the init function, outside of the promise change - This should be a minor optimisation, and again improves readability /clarity of what's happening * ✨ ⁉️ Move DBHash init / first run to Settings model - this structure is left over from when we had code we executed on the first run of Ghost - the implementation used the API to initialise one setting before populateDefaults is called - this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work - the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults() - it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!) - perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁 * ⏱ Optimise require order so config is first - the first require to config will cause the files to be read etc - this ensures that it happens early, and isn't confusingly timed as part of loading a different module * 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
defaultSettingsFlattened = {},
dynamicDefault = {
db_hash: () => uuid.v4(),
public_hash: () => crypto.randomBytes(15).toString('hex'),
Updated theme layer to use members-ssr (#10676) * Removed support for cookies in members auth middleware no-issue The members middleware will no longer be supporting cookies, the cookie will be handled by a new middleware specific for serverside rendering, more informations can be found here: https://paper.dropbox.com/doc/Members-Auth-II-4WP4vF6coMqDYbSMIajo5 * Removed members auth middleware from site app no-issue The site app no longer needs the members auth middleware as it doesn't support cookies, and will be replaced by ssr specific middleware. https://paper.dropbox.com/doc/Members-Auth-II-4WP4vF6coMqDYbSMIajo5 * Added comment for session_secret setting no-issue We are going to have multiple concepts of sessions, so adding a comment here to be specific that this is for the Ghost Admin client * Added theme_session_secret setting dynamic default no-issue Sessions for the theme layer will be signed, so we generate a random hex string to use as a signing key * Added getPublicConfig method * Replaced export of httpHandler with POJO apiInstance no-issue This is mainly to reduce the public api, so it's easier to document. * Renamed memberUserObject -> members no-issue Simplifies the interface, and is more inline with what we would want to export as an api library. * Removed use of require options inside members no-issue This was too tight of a coupling between Ghost and Members * Simplified apiInstance definition no-issue * Added getMember method to members api * Added MembersSSR instance to members service * Wired up routes for members ssr * Updated members auth middleware to use getPublicConfig * Removed publicKey static export from members service * Used real session secret no-issue * Added DELETE /members/ssr handler no-issue This allows users to log out of the theme layer * Fixed missing code property no-issue Ignition uses the statusCode property to forward status codes to call sites * Removed superfluous error middleware no-issue Before we used generic JWT middleware which would reject, now the middleware catches it's own error and doesn't error, thus this middleware is unecessary. * Removed console.logs no-issue * Updated token expirty to hardcoded 20 minutes no-issue This returns to our previous state of using short lived tokens, both for security and simplicity. * Removed hardcoded default member settings no-issue This is no longer needed, as defaults are in default-settings.json * Removed stripe from default payment processor no-issue * Exported `getSiteUrl` method from url utils no-issue This keeps inline with newer naming conventions * Updated how audience access control works no-issue Rather than being passed a function, members api now receives an object which describes which origins have access to which audiences, and how long those tokens should be allowed to work for. It also allows syntax for default tokens where audience === origin requesting it. This can be set to undefined or null to disable this functionality. { "http://site.com": { "http://site.com": { tokenLength: '5m' }, "http://othersite.com": { tokenLength: '1h' } }, "*": { tokenLength: '30m' } } * Updated members service to use access control feature no-issue This also cleans up a lot of unecessary variable definitions, and some other minor cleanups. * Added status code to auth pages html response no-issue This was missing, probably default but better to be explicit * Updated gateway to have membersApiUrl from config no-issue Previously we were parsing the url, this was not very safe as we can have Ghost hosted on a subdomain, and this would have failed. * Added issuer to public config for members no-issue This can be used to request SSR tokens in the client * Fixed path for gateway bundle no-issue * Updated settings model tests no-issue * Revert "Removed stripe from default payment processor" This reverts commit 1d88d9b6d73a10091070bcc1b7f5779d071c7845. * Revert "Removed hardcoded default member settings" This reverts commit 9d899048ba7d4b272b9ac65a95a52af66b30914a. * Installed @tryghost/members-ssr * Fixed tests for settings model
2019-04-16 17:50:25 +03:00
// @TODO: session_secret would ideally be named "admin_session_secret"
session_secret: () => crypto.randomBytes(32).toString('hex'),
members_session_secret: () => crypto.randomBytes(32).toString('hex'),
theme_session_secret: () => crypto.randomBytes(32).toString('hex'),
members_public_key: () => getMembersKey('public'),
members_private_key: () => getMembersKey('private')
🎨 ⏱ Cleanup / optimise the server.init() function (#7985) refs #2182 * 🔥 Remove unused options from server init - this is left over from old code and is now unused * 🎨 Move knex-migrator check to db health - Move complex check function into own module - Call module from server/index.js - This just improves the readability of server/index.js * 🔥 Remove old comments - These comments all make no sense now! * 🎨 ⏱ Move model init out of promise chain - Model.init() does not return a promise - Therefore, we can move it to the top of the init function, outside of the promise change - This should be a minor optimisation, and again improves readability /clarity of what's happening * ✨ ⁉️ Move DBHash init / first run to Settings model - this structure is left over from when we had code we executed on the first run of Ghost - the implementation used the API to initialise one setting before populateDefaults is called - this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work - the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults() - it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!) - perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁 * ⏱ Optimise require order so config is first - the first require to config will cause the files to be read etc - this ensures that it happens early, and isn't confusingly timed as part of loading a different module * 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
};
_.each(defaultSettingsInCategories, function each(settings, categoryName) {
_.each(settings, function each(setting, settingName) {
setting.type = categoryName;
setting.key = settingName;
setting.getDefaultValue = function getDefaultValue() {
const getDynamicDefault = dynamicDefault[setting.key];
if (getDynamicDefault) {
return getDynamicDefault();
} else {
return setting.defaultValue;
}
};
defaultSettingsFlattened[settingName] = setting;
});
});
return defaultSettingsFlattened;
}
function getDefaultSettings() {
if (!defaultSettings) {
defaultSettings = parseDefaultSettings();
}
return defaultSettings;
}
// Each setting is saved as a separate row in the database,
// but the overlying API treats them as a single key:value mapping
Settings = ghostBookshelf.Model.extend({
tableName: 'settings',
defaults: function defaults() {
return {
type: 'core'
};
},
emitChange: function emitChange(event, options) {
const eventToTrigger = 'settings' + '.' + event;
ghostBookshelf.Model.prototype.emitChange.bind(this)(this, eventToTrigger, options);
},
onDestroyed: function onDestroyed(model, options) {
ghostBookshelf.Model.prototype.onDestroyed.apply(this, arguments);
model.emitChange('deleted', options);
model.emitChange(model._previousAttributes.key + '.' + 'deleted', options);
},
onCreated: function onCreated(model, response, options) {
ghostBookshelf.Model.prototype.onCreated.apply(this, arguments);
model.emitChange('added', options);
model.emitChange(model.attributes.key + '.' + 'added', options);
},
onUpdated: function onUpdated(model, response, options) {
ghostBookshelf.Model.prototype.onUpdated.apply(this, arguments);
model.emitChange('edited', options);
model.emitChange(model.attributes.key + '.' + 'edited', options);
},
onValidate: function onValidate() {
var self = this;
return ghostBookshelf.Model.prototype.onValidate.apply(this, arguments)
.then(function then() {
return validation.validateSettings(getDefaultSettings(), self);
});
},
format() {
const attrs = ghostBookshelf.Model.prototype.format.apply(this, arguments);
// @NOTE: type TEXT will transform boolean to "0"
if (_.isBoolean(attrs.value)) {
attrs.value = attrs.value.toString();
}
return attrs;
},
parse() {
const attrs = ghostBookshelf.Model.prototype.parse.apply(this, arguments);
// transform "0" to false
// transform "false" to false
if (attrs.value === '0' || attrs.value === '1') {
attrs.value = !!+attrs.value;
}
if (attrs.value === 'false' || attrs.value === 'true') {
attrs.value = JSON.parse(attrs.value);
}
return attrs;
}
}, {
findOne: function (data, options) {
if (_.isEmpty(data)) {
options = data;
}
// Allow for just passing the key instead of attributes
if (!_.isObject(data)) {
data = {key: data};
}
return Promise.resolve(ghostBookshelf.Model.findOne.call(this, data, options));
},
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
edit: function (data, unfilteredOptions) {
var options = this.filterOptions(unfilteredOptions, 'edit'),
self = this;
if (!Array.isArray(data)) {
data = [data];
}
return Promise.map(data, function (item) {
// Accept an array of models as input
if (item.toJSON) {
item = item.toJSON();
}
if (!(_.isString(item.key) && item.key.length > 0)) {
return Promise.reject(new common.errors.ValidationError({message: common.i18n.t('errors.models.settings.valueCannotBeBlank')}));
}
item = self.filterData(item);
return Settings.forge({key: item.key}).fetch(options).then(function then(setting) {
if (setting) {
// it's allowed to edit all attributes in case of importing/migrating
if (options.importing) {
return setting.save(item, options);
} else {
// If we have a value, set it.
if (Object.prototype.hasOwnProperty.call(item, 'value')) {
setting.set('value', item.value);
}
// Internal context can overwrite type (for fixture migrations)
if (options.context && options.context.internal && Object.prototype.hasOwnProperty.call(item, 'type')) {
setting.set('type', item.type);
}
// If anything has changed, save the updated model
if (setting.hasChanged()) {
return setting.save(null, options);
}
return setting;
}
}
return Promise.reject(new common.errors.NotFoundError({message: common.i18n.t('errors.models.settings.unableToFindSetting', {key: item.key})}));
🎨 configurable logging with bunyan (#7431) - 🛠 add bunyan and prettyjson, remove morgan - ✨ add logging module - GhostLogger class that handles setup of bunyan - PrettyStream for stdout - ✨ config for logging - @TODO: testing level fatal? - ✨ log each request via GhostLogger (express middleware) - @TODO: add errors to output - 🔥 remove errors.updateActiveTheme - we can read the value from config - 🔥 remove 15 helper functions in core/server/errors/index.js - all these functions get replaced by modules: 1. logging 2. error middleware handling for html/json 3. error creation (which will be part of PR #7477) - ✨ add express error handler for html/json - one true error handler for express responses - contains still some TODO's, but they are not high priority for first implementation/integration - this middleware only takes responsibility of either rendering html responses or return json error responses - 🎨 use new express error handler in middleware/index - 404 and 500 handling - 🎨 return error instead of error message in permissions/index.js - the rule for error handling should be: if you call a unit, this unit should return a custom Ghost error - 🎨 wrap serve static module - rule: if you call a module/unit, you should always wrap this error - it's always the same rule - so the caller never has to worry about what comes back - it's always a clear error instance - in this case: we return our notfounderror if serve static does not find the resource - this avoid having checks everywhere - 🎨 replace usages of errors/index.js functions and adapt tests - use logging.error, logging.warn - make tests green - remove some usages of logging and throwing api errors -> because when a request is involved, logging happens automatically - 🐛 return errorDetails to Ghost-Admin - errorDetails is used for Theme error handling - 🎨 use 500er error for theme is missing error in theme-handler - 🎨 extend file rotation to 1w
2016-10-04 18:33:43 +03:00
});
});
},
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
populateDefaults: function populateDefaults(unfilteredOptions) {
var options = this.filterOptions(unfilteredOptions, 'populateDefaults'),
self = this;
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
if (!options.context) {
options.context = internalContext.context;
}
return this
.findAll(options)
.then(function checkAllSettings(allSettings) {
var usedKeys = allSettings.models.map(function mapper(setting) {
return setting.get('key');
}),
insertOperations = [];
_.each(getDefaultSettings(), function forEachDefault(defaultSetting, defaultSettingKey) {
var isMissingFromDB = usedKeys.indexOf(defaultSettingKey) === -1;
if (isMissingFromDB) {
defaultSetting.value = defaultSetting.getDefaultValue();
insertOperations.push(Settings.forge(defaultSetting).save(null, options));
}
});
if (insertOperations.length > 0) {
return Promise.all(insertOperations).then(function fetchAllToReturn() {
return self.findAll(options);
});
}
return allSettings;
});
}
});
module.exports = {
Settings: ghostBookshelf.model('Settings', Settings)
};