Ghost/ghost/core/test/e2e-api/admin/settings.test.js

695 lines
26 KiB
JavaScript
Raw Normal View History

const assert = require('assert/strict');
const sinon = require('sinon');
const logging = require('@tryghost/logging');
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
const SingleUseTokenProvider = require('../../../core/server/services/members/SingleUseTokenProvider');
🎨 Reduced favicon requirements and added image formatting (#14918) fixes https://github.com/TryGhost/Team/issues/1652 fixes https://github.com/TryGhost/Ghost/issues/13319 **Image formatting** Added support for changing the format of images via the `handle-image-sizes` middleware (e.g. format SVG to png, jpeg, webp) This change was required: - Not all browsers support SVG favicons, so we need to convert them to PNGs - We can't fit image resizing and formatting in the `serve-favicon` middleware: we need to store the resized image to avoid resizing on every request. This system was already present in the `handle-image-sizes` middleware. To format an uploaded image: - Original URL: https://localhost/blog/content/images/2022/05/giphy.gif - To resize: https://localhost/blog/content/images/size/w256h256/2022/05/giphy.gif (already supported) - To resize and format to webp: https://localhost/blog/content/images/size/w256h256/format/webp/2022/05/giphy.gif - Animations are preserved when converting Gifs to Webp and in reverse, and also when only resizing (https://github.com/TryGhost/Ghost/issues/13319) **Favicons** - Custom favicons are no longer served via `/favicon.png` or `/favicon.ico` (only for default favicon), but use their full path - Added support for uploading more image extensions in Ghost as a favicon: .jpg, .jpeg, .gif, .webp and .svg are now supported (already supported .png and .ico). - File extensions other than jpg/jpeg, png, or ico will always get transformed to the image/png format to guarantee browser support (webp and svg images are not yet supported as favicons by all browsers). For all image formats, other than .ico files: - Allowed to upload images larger than 1000px in width and height, they will get cropped to 256x256px. - Allowed uploading favicons that are not square. They will get cropped automatically. - Allowed to upload larger files, up to 20MB (will get served at a lower file size after being resized) For .svg files: - The minimum size of 60x60px is no longer required. For .ico files: - The file size limit is increased to 200kb (coming from 100kb)
2022-05-27 17:36:53 +03:00
const settingsCache = require('../../../core/shared/settings-cache');
const {agentProvider, fixtureManager, mockManager, matchers, configUtils} = require('../../utils/e2e-framework');
const {stringMatching, anyEtag, anyUuid, anyContentLength, anyContentVersion} = matchers;
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
const models = require('../../../core/server/models');
const {mockLabsDisabled, mockLabsEnabled} = require('../../utils/e2e-framework-mock-manager');
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
const {anyErrorId} = matchers;
2018-10-12 20:44:02 +03:00
const CURRENT_SETTINGS_COUNT = 86;
2018-10-12 20:44:02 +03:00
const settingsMatcher = {};
2018-10-12 20:44:02 +03:00
const publicHashSettingMatcher = {
value: stringMatching(/[a-z0-9]{30}/)
};
2018-10-12 20:44:02 +03:00
const labsSettingMatcher = {
value: stringMatching(/\{[^\s]+\}/)
};
const matchSettingsArray = (length) => {
const settingsArray = new Array(length).fill(settingsMatcher);
2018-10-12 20:44:02 +03:00
if (length > 26) {
// Added a setting that is alphabetically before 'public_hash'? then you need to increment this counter.
// Item at index x is the public hash, which is always different
settingsArray[26] = publicHashSettingMatcher;
}
2018-10-12 20:44:02 +03:00
if (length > 60) {
// Added a setting that is alphabetically before 'labs'? then you need to increment this counter.
// Item at index x is the lab settings, which changes as we add and remove features
settingsArray[60] = labsSettingMatcher;
}
return settingsArray;
};
2018-10-12 20:44:02 +03:00
describe('Settings API', function () {
let agent;
2018-10-12 20:44:02 +03:00
before(async function () {
agent = await agentProvider.getAdminAPIAgent();
await fixtureManager.init();
await agent.loginAsOwner();
});
beforeEach(function () {
mockManager.mockMail();
Added email address alignment protections (#19094) ref GRO-54 fixes GRO-63 fixes GRO-62 fixes GRO-69 When the config `hostSettings:managedEmail:enabled` is enabled, or the new flag (`newEmailAddresses`) is enabled for self-hosters, we'll start to check the from addresses of all outgoing emails more strictly. - Current flow: nothing changes if the managedEmail config is not set or the `newEmailAddresses` feature flag is not set - When managedEmail is enabled: never allow to send an email from any chosen email. We always use `mail.from` for all outgoing emails. Custom addresses should be set as replyTo instead. Changing the newsletter sender_email is not allowed anymore (and ignored if it is set). - When managedEmail is enabled with a custom sending domain: if a from address doesn't match the sending domain, we'll default to mail.from and use the original as a replyTo if appropriate and only when no other replyTo was set. A newsletter sender email addresss can only be set to an email address on this domain. - When `newEmailAddresses` is enabled: self hosters are free to set all email addresses to whatever they want, without verification. In addition to that, we stop making up our own email addresses and send from `mail.from` by default instead of generating a `noreply`+ `@` + `sitedomain.com` address A more in depth example of all cases can be seen in `ghost/core/test/integration/services/email-addresses.test.js` Includes lots of new E2E tests for most new situations. Apart from that, all email snapshots are changed because the from and replyTo addresses are now included in snapshots (so we can see unexpected changes in the future). Dropped test coverage requirement, because tests were failing coverage locally, but not in CI Fixed settings test that set the site title to an array - bug tracked in GRO-68
2023-11-23 12:25:30 +03:00
mockLabsDisabled('newEmailAddresses');
});
afterEach(function () {
mockManager.restore();
sinon.restore();
});
2018-10-12 20:44:02 +03:00
describe('Browse', function () {
it('Can request all settings', async function () {
await agent
.get('settings/')
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
});
});
it('Can request settings by group', async function () {
await agent
.get('settings/?group=theme')
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(1)
})
.matchHeaderSnapshot({
'content-version': anyContentVersion,
etag: anyEtag
});
});
it('Requesting core settings by group ignores the parameter and returns no settings', async function () {
await agent
.get('settings/?group=core')
.expectStatus(200)
.matchBodySnapshot()
.matchHeaderSnapshot({
'content-version': anyContentVersion,
etag: anyEtag
});
});
2018-10-12 20:44:02 +03:00
});
describe('Edit', function () {
it('Can edit a setting', async function () {
const settingsToChange = [
{
key: 'title',
Added email address alignment protections (#19094) ref GRO-54 fixes GRO-63 fixes GRO-62 fixes GRO-69 When the config `hostSettings:managedEmail:enabled` is enabled, or the new flag (`newEmailAddresses`) is enabled for self-hosters, we'll start to check the from addresses of all outgoing emails more strictly. - Current flow: nothing changes if the managedEmail config is not set or the `newEmailAddresses` feature flag is not set - When managedEmail is enabled: never allow to send an email from any chosen email. We always use `mail.from` for all outgoing emails. Custom addresses should be set as replyTo instead. Changing the newsletter sender_email is not allowed anymore (and ignored if it is set). - When managedEmail is enabled with a custom sending domain: if a from address doesn't match the sending domain, we'll default to mail.from and use the original as a replyTo if appropriate and only when no other replyTo was set. A newsletter sender email addresss can only be set to an email address on this domain. - When `newEmailAddresses` is enabled: self hosters are free to set all email addresses to whatever they want, without verification. In addition to that, we stop making up our own email addresses and send from `mail.from` by default instead of generating a `noreply`+ `@` + `sitedomain.com` address A more in depth example of all cases can be seen in `ghost/core/test/integration/services/email-addresses.test.js` Includes lots of new E2E tests for most new situations. Apart from that, all email snapshots are changed because the from and replyTo addresses are now included in snapshots (so we can see unexpected changes in the future). Dropped test coverage requirement, because tests were failing coverage locally, but not in CI Fixed settings test that set the site title to an array - bug tracked in GRO-68
2023-11-23 12:25:30 +03:00
value: ''
},
{
key: 'codeinjection_head',
value: null
},
{
key: 'announcement_content',
value: '<p>Great news coming soon!</p>'
},
{
key: 'announcement_visibility',
value: JSON.stringify(['visitors', 'free_members'])
},
{
key: 'navigation',
value: JSON.stringify([{
label: 'label1'
}])
},
{
key: 'slack_username',
value: 'New Slack Username'
},
{
key: 'is_private',
value: false
},
{
key: 'meta_title',
value: 'SEO title'
},
{
key: 'meta_description',
value: 'SEO description'
},
{
key: 'og_image',
value: '/content/images/2019/07/facebook.png'
},
{
key: 'og_title',
value: 'facebook title'
},
{
key: 'og_description',
value: 'facebook description'
},
{
key: 'twitter_image',
value: '/content/images/2019/07/twitter.png'
},
{
key: 'twitter_title',
value: 'twitter title'
},
{
key: 'twitter_description',
value: 'twitter description'
},
{
key: 'locale',
value: 'ua'
},
{
key: 'labs',
value: JSON.stringify({})
},
{
key: 'timezone',
value: 'Pacific/Auckland'
},
{
key: 'unsplash',
value: false
}
];
await agent.put('settings/')
.body({
settings: settingsToChange
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
'content-version': anyContentVersion,
etag: anyEtag
});
mockManager.assert.sentEmailCount(0);
});
🎨 Reduced favicon requirements and added image formatting (#14918) fixes https://github.com/TryGhost/Team/issues/1652 fixes https://github.com/TryGhost/Ghost/issues/13319 **Image formatting** Added support for changing the format of images via the `handle-image-sizes` middleware (e.g. format SVG to png, jpeg, webp) This change was required: - Not all browsers support SVG favicons, so we need to convert them to PNGs - We can't fit image resizing and formatting in the `serve-favicon` middleware: we need to store the resized image to avoid resizing on every request. This system was already present in the `handle-image-sizes` middleware. To format an uploaded image: - Original URL: https://localhost/blog/content/images/2022/05/giphy.gif - To resize: https://localhost/blog/content/images/size/w256h256/2022/05/giphy.gif (already supported) - To resize and format to webp: https://localhost/blog/content/images/size/w256h256/format/webp/2022/05/giphy.gif - Animations are preserved when converting Gifs to Webp and in reverse, and also when only resizing (https://github.com/TryGhost/Ghost/issues/13319) **Favicons** - Custom favicons are no longer served via `/favicon.png` or `/favicon.ico` (only for default favicon), but use their full path - Added support for uploading more image extensions in Ghost as a favicon: .jpg, .jpeg, .gif, .webp and .svg are now supported (already supported .png and .ico). - File extensions other than jpg/jpeg, png, or ico will always get transformed to the image/png format to guarantee browser support (webp and svg images are not yet supported as favicons by all browsers). For all image formats, other than .ico files: - Allowed to upload images larger than 1000px in width and height, they will get cropped to 256x256px. - Allowed uploading favicons that are not square. They will get cropped automatically. - Allowed to upload larger files, up to 20MB (will get served at a lower file size after being resized) For .svg files: - The minimum size of 60x60px is no longer required. For .ico files: - The file size limit is increased to 200kb (coming from 100kb)
2022-05-27 17:36:53 +03:00
it('removes image size prefixes when setting the icon', async function () {
const settingsToChange = [
{
key: 'icon',
value: '/content/images/size/w256h256/2019/07/icon.png'
}
];
const {body} = await agent.put('settings/')
.body({
settings: settingsToChange
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
🎨 Reduced favicon requirements and added image formatting (#14918) fixes https://github.com/TryGhost/Team/issues/1652 fixes https://github.com/TryGhost/Ghost/issues/13319 **Image formatting** Added support for changing the format of images via the `handle-image-sizes` middleware (e.g. format SVG to png, jpeg, webp) This change was required: - Not all browsers support SVG favicons, so we need to convert them to PNGs - We can't fit image resizing and formatting in the `serve-favicon` middleware: we need to store the resized image to avoid resizing on every request. This system was already present in the `handle-image-sizes` middleware. To format an uploaded image: - Original URL: https://localhost/blog/content/images/2022/05/giphy.gif - To resize: https://localhost/blog/content/images/size/w256h256/2022/05/giphy.gif (already supported) - To resize and format to webp: https://localhost/blog/content/images/size/w256h256/format/webp/2022/05/giphy.gif - Animations are preserved when converting Gifs to Webp and in reverse, and also when only resizing (https://github.com/TryGhost/Ghost/issues/13319) **Favicons** - Custom favicons are no longer served via `/favicon.png` or `/favicon.ico` (only for default favicon), but use their full path - Added support for uploading more image extensions in Ghost as a favicon: .jpg, .jpeg, .gif, .webp and .svg are now supported (already supported .png and .ico). - File extensions other than jpg/jpeg, png, or ico will always get transformed to the image/png format to guarantee browser support (webp and svg images are not yet supported as favicons by all browsers). For all image formats, other than .ico files: - Allowed to upload images larger than 1000px in width and height, they will get cropped to 256x256px. - Allowed uploading favicons that are not square. They will get cropped automatically. - Allowed to upload larger files, up to 20MB (will get served at a lower file size after being resized) For .svg files: - The minimum size of 60x60px is no longer required. For .ico files: - The file size limit is increased to 200kb (coming from 100kb)
2022-05-27 17:36:53 +03:00
});
🎨 Reduced favicon requirements and added image formatting (#14918) fixes https://github.com/TryGhost/Team/issues/1652 fixes https://github.com/TryGhost/Ghost/issues/13319 **Image formatting** Added support for changing the format of images via the `handle-image-sizes` middleware (e.g. format SVG to png, jpeg, webp) This change was required: - Not all browsers support SVG favicons, so we need to convert them to PNGs - We can't fit image resizing and formatting in the `serve-favicon` middleware: we need to store the resized image to avoid resizing on every request. This system was already present in the `handle-image-sizes` middleware. To format an uploaded image: - Original URL: https://localhost/blog/content/images/2022/05/giphy.gif - To resize: https://localhost/blog/content/images/size/w256h256/2022/05/giphy.gif (already supported) - To resize and format to webp: https://localhost/blog/content/images/size/w256h256/format/webp/2022/05/giphy.gif - Animations are preserved when converting Gifs to Webp and in reverse, and also when only resizing (https://github.com/TryGhost/Ghost/issues/13319) **Favicons** - Custom favicons are no longer served via `/favicon.png` or `/favicon.ico` (only for default favicon), but use their full path - Added support for uploading more image extensions in Ghost as a favicon: .jpg, .jpeg, .gif, .webp and .svg are now supported (already supported .png and .ico). - File extensions other than jpg/jpeg, png, or ico will always get transformed to the image/png format to guarantee browser support (webp and svg images are not yet supported as favicons by all browsers). For all image formats, other than .ico files: - Allowed to upload images larger than 1000px in width and height, they will get cropped to 256x256px. - Allowed uploading favicons that are not square. They will get cropped automatically. - Allowed to upload larger files, up to 20MB (will get served at a lower file size after being resized) For .svg files: - The minimum size of 60x60px is no longer required. For .ico files: - The file size limit is increased to 200kb (coming from 100kb)
2022-05-27 17:36:53 +03:00
// Check returned WITH prefix
const val = body.settings.find(setting => setting.key === 'icon');
assert.ok(val);
assert.equal(val.value, 'http://127.0.0.1:2369/content/images/size/w256h256/2019/07/icon.png');
// Check if not changed (also check internal ones)
const afterValue = settingsCache.get('icon');
assert.equal(afterValue, 'http://127.0.0.1:2369/content/images/2019/07/icon.png');
mockManager.assert.sentEmailCount(0);
🎨 Reduced favicon requirements and added image formatting (#14918) fixes https://github.com/TryGhost/Team/issues/1652 fixes https://github.com/TryGhost/Ghost/issues/13319 **Image formatting** Added support for changing the format of images via the `handle-image-sizes` middleware (e.g. format SVG to png, jpeg, webp) This change was required: - Not all browsers support SVG favicons, so we need to convert them to PNGs - We can't fit image resizing and formatting in the `serve-favicon` middleware: we need to store the resized image to avoid resizing on every request. This system was already present in the `handle-image-sizes` middleware. To format an uploaded image: - Original URL: https://localhost/blog/content/images/2022/05/giphy.gif - To resize: https://localhost/blog/content/images/size/w256h256/2022/05/giphy.gif (already supported) - To resize and format to webp: https://localhost/blog/content/images/size/w256h256/format/webp/2022/05/giphy.gif - Animations are preserved when converting Gifs to Webp and in reverse, and also when only resizing (https://github.com/TryGhost/Ghost/issues/13319) **Favicons** - Custom favicons are no longer served via `/favicon.png` or `/favicon.ico` (only for default favicon), but use their full path - Added support for uploading more image extensions in Ghost as a favicon: .jpg, .jpeg, .gif, .webp and .svg are now supported (already supported .png and .ico). - File extensions other than jpg/jpeg, png, or ico will always get transformed to the image/png format to guarantee browser support (webp and svg images are not yet supported as favicons by all browsers). For all image formats, other than .ico files: - Allowed to upload images larger than 1000px in width and height, they will get cropped to 256x256px. - Allowed uploading favicons that are not square. They will get cropped automatically. - Allowed to upload larger files, up to 20MB (will get served at a lower file size after being resized) For .svg files: - The minimum size of 60x60px is no longer required. For .ico files: - The file size limit is increased to 200kb (coming from 100kb)
2022-05-27 17:36:53 +03:00
});
it('cannot edit uneditable settings', async function () {
await agent.put('settings/')
.body({
settings: [{key: 'email_verification_required', value: true}]
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
})
.expect(({body}) => {
const emailVerificationRequired = body.settings.find(setting => setting.key === 'email_verification_required');
assert.equal(emailVerificationRequired.value, false);
});
mockManager.assert.sentEmailCount(0);
});
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
it('[LEGACY] editing members_support_address triggers email verification flow', async function () {
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
await agent.put('settings/')
.body({
settings: [{key: 'members_support_address', value: 'support@example.com'}]
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
})
.expect(({body}) => {
const membersSupportAddress = body.settings.find(setting => setting.key === 'members_support_address');
assert.equal(membersSupportAddress.value, 'noreply');
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
assert.deepEqual(body.meta, {
sent_email_verification: ['members_support_address']
});
});
mockManager.assert.sentEmailCount(1);
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
mockManager.assert.sentEmail({
subject: 'Verify email address',
to: 'support@example.com'
});
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
});
it('does not trigger email verification flow if members_support_address remains the same', async function () {
await models.Settings.edit({
key: 'members_support_address',
value: 'support@example.com'
});
await agent.put('settings/')
.body({
settings: [{key: 'members_support_address', value: 'support@example.com'}]
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
})
.expect(({body}) => {
const membersSupportAddress = body.settings.find(setting => setting.key === 'members_support_address');
assert.equal(membersSupportAddress.value, 'support@example.com');
assert.deepEqual(body.meta, {});
});
mockManager.assert.sentEmailCount(0);
});
it('fails to edit setting with unsupported announcement_visibility value', async function () {
const loggingStub = sinon.stub(logging, 'error');
const settingsToChange = [
{
key: 'announcement_visibility',
value: JSON.stringify(['invalid value'])
}
];
await agent.put('settings/')
.body({
settings: settingsToChange
})
.expectStatus(422)
.matchBodySnapshot({
errors: [
{
id: anyErrorId
}
]
})
.matchHeaderSnapshot({
'content-version': anyContentVersion,
etag: anyEtag
});
sinon.assert.calledOnce(loggingStub);
});
it('fails to edit setting with unsupported announcement_background value', async function () {
const loggingStub = sinon.stub(logging, 'error');
const settingsToChange = [
{
key: 'announcement_background',
value: 'not a background value'
}
];
await agent.put('settings/')
.body({
settings: settingsToChange
})
.expectStatus(422)
.matchBodySnapshot({
errors: [
{
id: anyErrorId
}
]
})
.matchHeaderSnapshot({
'content-version': anyContentVersion,
etag: anyEtag
});
sinon.assert.calledOnce(loggingStub);
});
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
});
describe('verify key update', function () {
it('can update members_support_address via token', async function () {
const token = await (new SingleUseTokenProvider({
SingleUseTokenModel: models.SingleUseToken,
validityPeriod: 24 * 60 * 60 * 1000,
validityPeriodAfterUsage: 10 * 60 * 1000,
maxUsageCount: 1
})).create({key: 'members_support_address', value: 'support@example.com'});
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
await agent.put('settings/verifications/')
.body({
token
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
})
.expect(({body}) => {
const membersSupportAddress = body.settings.find(setting => setting.key === 'members_support_address');
assert.equal(membersSupportAddress.value, 'support@example.com');
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
});
mockManager.assert.sentEmailCount(0);
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
});
it('cannot update invalid keys via token', async function () {
const loggingStub = sinon.stub(logging, 'error');
const token = await (new SingleUseTokenProvider({
SingleUseTokenModel: models.SingleUseToken,
validityPeriod: 24 * 60 * 60 * 1000,
validityPeriodAfterUsage: 10 * 60 * 1000,
maxUsageCount: 1
})).create({key: 'members_support_address_invalid', value: 'support@example.com'});
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
await agent.put('settings/verifications/')
.body({
token
})
.expectStatus(400)
.matchBodySnapshot({
errors: [
{
id: anyErrorId
}
]
})
.matchHeaderSnapshot({
'content-version': anyContentVersion,
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
etag: anyEtag
});
sinon.assert.calledOnce(loggingStub);
🐛 Updated support email verification flow (#15029) refs https://github.com/TryGhost/Team/issues/584 The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong. To fix this, this commit updates the whole flow to use the same pattern as newsletters: - You can update the `members_support_address` setting directly via the edit endpoint of settings. - Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically. - When an email verification has been sent, the meta property `sent_email_verification` is set. Other changes: - Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'. - Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour. - The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error. Future changes: - Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this. Changes to admin: https://github.com/TryGhost/Admin/pull/2426
2022-07-15 15:43:52 +03:00
});
2018-10-12 20:44:02 +03:00
});
describe('stripe connect', function () {
it('can do disconnectStripeConnectIntegration', async function () {
await agent
.delete('/settings/stripe/connect/')
.expectStatus(204)
.expectEmptyBody()
.matchHeaderSnapshot({
'content-version': anyContentVersion,
etag: anyEtag
});
const stripeSettings = [
'stripe_connect_publishable_key',
'stripe_connect_secret_key',
'stripe_connect_livemode',
'stripe_connect_display_name',
'stripe_connect_account_id',
'members_stripe_webhook_id',
'members_stripe_webhook_secret'
];
// Assert that the settings are changed as a side effect
await agent.get('settings/')
.expect(({body}) => {
body.settings.forEach((setting) => {
if (stripeSettings.includes(setting.key)) {
assert.equal(setting.value, null);
}
});
});
});
it('Can attempt to connect to stripe', async function () {
const settingsToChange = [
{
key: 'stripe_connect_integration_token',
value: JSON.stringify({
s: 'session_state',
p: 'public_key',
a: 'secret_key',
l: true,
n: 'Display Name',
i: 'account_id'
})
}
];
await agent.put('settings/')
.body({
settings: settingsToChange
})
.expectStatus(400)
.matchBodySnapshot({
errors: [{
id: anyUuid
}]
})
.matchHeaderSnapshot({
'content-version': anyContentVersion,
etag: anyEtag
});
});
});
describe('Managed email without custom sending domain', function () {
this.beforeEach(function () {
configUtils.set('hostSettings:managedEmail:enabled', true);
configUtils.set('hostSettings:managedEmail:sendingDomain', null);
configUtils.set('mail:from', 'default@email.com');
});
it('editing members_support_address triggers email verification flow', async function () {
const currentSetting = settingsCache.get('members_support_address');
assert(currentSetting !== 'othersupport@example.com', 'This test requires a changed email address');
await agent.put('settings/')
.body({
settings: [{key: 'members_support_address', value: 'othersupport@example.com'}]
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
})
.expect(({body}) => {
const membersSupportAddress = body.settings.find(setting => setting.key === 'members_support_address');
assert.equal(membersSupportAddress.value, currentSetting);
assert.deepEqual(body.meta, {
sent_email_verification: ['members_support_address']
});
});
mockManager.assert.sentEmailCount(1);
mockManager.assert.sentEmail({
subject: 'Verify email address',
to: 'othersupport@example.com'
});
});
it('editing members_support_address equaling default does not trigger verification flow', async function () {
await agent.put('settings/')
.body({
settings: [{key: 'members_support_address', value: 'default@email.com'}]
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
});
mockManager.assert.sentEmailCount(0);
});
});
describe('Managed email with custom sending domain', function () {
this.beforeEach(function () {
configUtils.set('hostSettings:managedEmail:enabled', true);
configUtils.set('hostSettings:managedEmail:sendingDomain', 'sendingdomain.com');
configUtils.set('mail:from', 'default@email.com');
});
it('editing members_support_address without matching domain triggers email verification flow', async function () {
const currentSetting = settingsCache.get('members_support_address');
assert(currentSetting !== 'othersupport@example.com', 'This test requires a changed email address');
await agent.put('settings/')
.body({
settings: [{key: 'members_support_address', value: 'othersupport@example.com'}]
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
})
.expect(({body}) => {
const membersSupportAddress = body.settings.find(setting => setting.key === 'members_support_address');
assert.equal(membersSupportAddress.value, currentSetting);
assert.deepEqual(body.meta, {
sent_email_verification: ['members_support_address']
});
});
mockManager.assert.sentEmailCount(1);
mockManager.assert.sentEmail({
subject: 'Verify email address',
to: 'othersupport@example.com'
});
});
it('editing members_support_address with matching domain does not trigger email verification flow', async function () {
const currentSetting = settingsCache.get('members_support_address');
assert(currentSetting !== 'support@sendingdomain.com', 'This test requires a changed email address');
await agent.put('settings/')
.body({
settings: [{key: 'members_support_address', value: 'support@sendingdomain.com'}]
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
});
mockManager.assert.sentEmailCount(0);
});
it('editing members_support_address equaling default does not trigger verification flow', async function () {
await agent.put('settings/')
.body({
settings: [{key: 'members_support_address', value: 'default@email.com'}]
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
});
mockManager.assert.sentEmailCount(0);
});
});
describe('Self hoster without managed email', function () {
this.beforeEach(function () {
configUtils.set('hostSettings:managedEmail:enabled', false);
configUtils.set('hostSettings:managedEmail:sendingDomain', '');
mockLabsEnabled('newEmailAddresses');
});
it('editing members_support_address does not trigger email verification flow', async function () {
const currentSetting = settingsCache.get('members_support_address');
assert(currentSetting !== 'support@customdomain.com', 'This test requires a changed email address');
await agent.put('settings/')
.body({
settings: [{key: 'members_support_address', value: 'support@customdomain.com'}]
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
});
mockManager.assert.sentEmailCount(0);
});
it('editing members_support_address equaling default does not trigger verification flow', async function () {
await agent.put('settings/')
.body({
settings: [{key: 'members_support_address', value: 'default@email.com'}]
})
.expectStatus(200)
.matchBodySnapshot({
settings: matchSettingsArray(CURRENT_SETTINGS_COUNT)
})
.matchHeaderSnapshot({
etag: anyEtag,
// Special rule for this test, as the labs setting changes a lot
'content-length': anyContentLength,
'content-version': anyContentVersion
});
mockManager.assert.sentEmailCount(0);
});
});
2018-10-12 20:44:02 +03:00
});