Ghost/ghost/core/test/utils/e2e-framework.js

510 lines
17 KiB
JavaScript
Raw Normal View History

// Set of common function that should be main building blocks for e2e tests.
// The e2e tests usually consist of following building blocks:
// - request agent
// - state builder
// - output state checker (in case we don't get jest snapshots working)
//
2022-08-30 11:39:46 +03:00
// The request agent is responsible for making HTTP-like requests to an application (express app in case of Ghost).
// Note there's no actual need to make an HTTP request to an actual server, bypassing HTTP and hooking into the application
// directly is enough and reduces dependence on blocking a port (allows to run tests in parallel).
//
// The state builder is responsible for building the state of the application. Usually it's done by using pre-defined fixtures.
// Can include building a DB state, file system state (themes, config files), building configuration state (config files) etc.
//
// The output state checker is responsible for checking the response from the app after performing a request.
const _ = require('lodash');
const debug = require('@tryghost/debug')('test');
const {sequence} = require('@tryghost/promise');
const {any, stringMatching} = require('@tryghost/express-test').snapshot;
const {AsymmetricMatcher} = require('expect');
const fs = require('fs-extra');
const path = require('path');
const os = require('os');
const uuid = require('uuid');
const fixtureUtils = require('./fixture-utils');
const redirectsUtils = require('./redirects');
const configUtils = require('./configUtils');
const urlServiceUtils = require('./url-service-utils');
const mockManager = require('./e2e-framework-mock-manager');
const mentionsJobsService = require('../../core/server/services/mentions-jobs');
const jobsService = require('../../core/server/services/jobs');
const boot = require('../../core/boot');
const {AdminAPITestAgent, ContentAPITestAgent, GhostAPITestAgent, MembersAPITestAgent} = require('./agents');
const db = require('./db-utils');
// Services that need resetting
const settingsService = require('../../core/server/services/settings/settings-service');
const supertest = require('supertest');
Fixed configUtils and adapter cache issues in E2E tests (#16167) no issue There are a couple of issues with resetting the Ghost instance between E2E test files: These issues came to the surface because of new tests written in https://github.com/TryGhost/Ghost/pull/16117 **1. configUtils.restore does not work correctly** `config.reset()` is a callback based method. On top of that, it doesn't really work reliably (https://github.com/indexzero/nconf/issues/93) What kinda happens, is that you first call `config.reset` but immediately after you correcty reset the config using the `config.set` calls afterwards. But since `config.reset` is async, that reset will happen after all those sets, and the end result is that it isn't reset correctly. This mainly caused issues in the new updated images tests, which were updating the config `imageOptimization.contentImageSizes`, which is a deeply nested config value. Maybe some references to objects are reused in nconf that cause this issue? Wrapping `config.reset()` in a promise does fix the issue. **2. Adapters cache not reset between tests** At the start of each test, we set `paths:contentPath` to a nice new temporary directory. But if a previous test already requests a localStorage adapter, that adapter would have been created and in the constructor `paths:contentPath` would have been passed. That same instance will be reused in the next test run. So it won't read the new config again. To fix this, we need to reset the adapter instances between E2E tests. How was this visible? Test uploads were stored in the actual git repository, and not in a temporary directory. When writing the new image upload tests, this also resulted in unreliable test runs because some image names were already taken (from previous test runs). **3. Old 2E2 test Ghost server not stopped** Sometimes we still need access to the frontend test server using `getAgentsWithFrontend`. But that does start a new Ghost server which is actually listening for HTTP traffic. This could result in a fatal error in tests because the port is already in use. The issue is that old E2E tests also start a HTTP server, but they don't stop the server. When you used the old `startGhost` util, it would check if a server was already running and stop it first. The new `getAgentsWithFrontend` now also has the same functionality to fix that issue.
2023-01-30 16:06:20 +03:00
const {stopGhost} = require('./e2e-utils');
const adapterManager = require('../../core/server/services/adapter-manager');
const DomainEvents = require('@tryghost/domain-events');
// Require additional assertions which help us keep our tests small and clear
require('./assertions');
let totalResetTime = 0;
let totalStartTime = 0;
let totalBoots = 0;
/**
* @param {Object} [options={}]
* @param {Boolean} [options.backend] Boot the backend
* @param {Boolean} [options.frontend] Boot the frontend
* @param {Boolean} [options.server] Start a server
* @returns {Promise<Express.Application>} ghost
*/
const startGhost = async (options = {}) => {
await mentionsJobsService.allSettled();
await jobsService.allSettled();
await DomainEvents.allSettled();
/**
* We never use the root content folder for testing!
* We use a tmp folder.
*/
const contentFolder = path.join(os.tmpdir(), uuid.v4(), 'ghost-test');
await prepareContentFolder({contentFolder});
// NOTE: need to pass this config to the server instance
configUtils.set('paths:contentPath', contentFolder);
Fixed configUtils and adapter cache issues in E2E tests (#16167) no issue There are a couple of issues with resetting the Ghost instance between E2E test files: These issues came to the surface because of new tests written in https://github.com/TryGhost/Ghost/pull/16117 **1. configUtils.restore does not work correctly** `config.reset()` is a callback based method. On top of that, it doesn't really work reliably (https://github.com/indexzero/nconf/issues/93) What kinda happens, is that you first call `config.reset` but immediately after you correcty reset the config using the `config.set` calls afterwards. But since `config.reset` is async, that reset will happen after all those sets, and the end result is that it isn't reset correctly. This mainly caused issues in the new updated images tests, which were updating the config `imageOptimization.contentImageSizes`, which is a deeply nested config value. Maybe some references to objects are reused in nconf that cause this issue? Wrapping `config.reset()` in a promise does fix the issue. **2. Adapters cache not reset between tests** At the start of each test, we set `paths:contentPath` to a nice new temporary directory. But if a previous test already requests a localStorage adapter, that adapter would have been created and in the constructor `paths:contentPath` would have been passed. That same instance will be reused in the next test run. So it won't read the new config again. To fix this, we need to reset the adapter instances between E2E tests. How was this visible? Test uploads were stored in the actual git repository, and not in a temporary directory. When writing the new image upload tests, this also resulted in unreliable test runs because some image names were already taken (from previous test runs). **3. Old 2E2 test Ghost server not stopped** Sometimes we still need access to the frontend test server using `getAgentsWithFrontend`. But that does start a new Ghost server which is actually listening for HTTP traffic. This could result in a fatal error in tests because the port is already in use. The issue is that old E2E tests also start a HTTP server, but they don't stop the server. When you used the old `startGhost` util, it would check if a server was already running and stop it first. The new `getAgentsWithFrontend` now also has the same functionality to fix that issue.
2023-01-30 16:06:20 +03:00
// Adapter cache has to be cleared to avoid reusing cached adapter instances between restarts
adapterManager.clearCache();
// Reset the URL service so we clear out all the listeners
urlServiceUtils.resetGenerators();
const defaults = {
backend: true,
frontend: false,
server: false
};
// Ensure the state of all data, including DB and caches
const resetDataNow = Date.now();
await resetData();
totalResetTime += Date.now() - resetDataNow;
const bootOptions = Object.assign({}, defaults, options);
const bootNow = Date.now();
const ghostServer = await boot(bootOptions);
const bootTime = Date.now() - bootNow;
totalStartTime += bootTime;
totalBoots += 1;
if (bootOptions.frontend) {
await urlServiceUtils.isFinished();
}
// Disable network in tests at the start
mockManager.disableNetwork();
debug(`[e2e-framework] Started Ghost in ${bootTime / 1000}s`);
debug(`[e2e-framework] Accumulated start time across ${totalBoots} boots is ${totalStartTime / 1000}s (average = ${Math.round(totalStartTime / totalBoots)}ms)`);
debug(`[e2e-framework] Accumulated reset time across ${totalBoots} boots is ${totalResetTime / 1000}s (average = ${Math.round(totalResetTime / totalBoots)}ms)`);
return ghostServer;
};
/**
* Slightly simplified copy-paste from e2e-utils.
* @param {Object} options
*/
const prepareContentFolder = async ({contentFolder, redirectsFile = true, routesFile = true}) => {
const contentFolderForTests = contentFolder;
await fs.ensureDir(contentFolderForTests);
await fs.ensureDir(path.join(contentFolderForTests, 'data'));
await fs.ensureDir(path.join(contentFolderForTests, 'themes'));
await fs.ensureDir(path.join(contentFolderForTests, 'images'));
await fs.ensureDir(path.join(contentFolderForTests, 'logs'));
await fs.ensureDir(path.join(contentFolderForTests, 'adapters'));
await fs.ensureDir(path.join(contentFolderForTests, 'settings'));
// Copy all themes into the new test content folder. Default active theme is always source.
// If you want to use a different theme, you have to set the active theme (e.g. stub)
await fs.copy(
path.join(__dirname, 'fixtures', 'themes'),
path.join(contentFolderForTests, 'themes')
);
if (redirectsFile) {
redirectsUtils.setupFile(contentFolderForTests, '.yaml');
}
if (routesFile) {
await fs.copy(
path.join(__dirname, 'fixtures', 'settings', 'routes.yaml'),
path.join(contentFolderForTests, 'settings', 'routes.yaml')
);
}
};
/**
* Database state builder. By default inserts an owner user into the database.
* @param {...any} [options]
* @returns {Promise<void>}
*/
const initFixtures = async (...options) => {
// No DB setup, but override the owner
options = _.merge({'owner:post': true}, _.transform(options, function (result, val) {
if (val) {
result[val] = true;
}
}));
const fixtureOps = fixtureUtils.getFixtureOps(options);
return sequence(fixtureOps);
};
const getFixture = (type, index = 0) => {
return fixtureUtils.DataGenerator.forKnex[type][index];
};
🔒 Prevented member creation when logging in (#15526) fixes https://github.com/TryGhost/Ghost/issues/14508 This change requires the frontend to send an explicit `emailType` when sending a magic link. We default to `subscribe` (`signin` for invite only sites) for now to remain compatible with the existing behaviour. **Problem:** When a member tries to login and that member doesn't exist, we created a new member in the past. - This caused the creation of duplicate accounts when members were guessing the email address they used. - This caused the creation of new accounts when using an old impersonation token, login link or email change link that was sent before member deletion. **Fixed:** - Trying to login with an email address that doesn't exist will throw an error now. - Added new and separate rate limiting to login (to prevent user enumeration). This rate limiting has a higher default limit of 8. I think it needs a higher default limit (because it is rate limited on every call instead of per email address. And it should be configurable independent from administrator rate limiting. It also needs a lower lifetime value because it is never reset. - Updated error responses in the `sendMagicLink` endpoint to use the default error encoding middleware. - The type (`signin`, `signup`, `updateEmail` or `subscribe`) is now stored in the magic link. This is used to prevent signups with a sign in token. **Notes:** - Between tests, we truncate the database, but this is not enough for the rate limits to be truly reset. I had to add a method to the spam prevention service to reset all the instances between tests. Not resetting them caused random failures because every login in every test was hitting those spam prevention middlewares and somehow left a trace of that in those instances (even when the brute table is reset). Maybe those instances were doing some in memory caching.
2022-10-05 13:42:42 +03:00
/**
* Reset rate limit instances (not the brute table)
*/
const resetRateLimits = async () => {
// Reset rate limiting instances
const {spamPrevention} = require('../../core/server/web/shared/middleware/api');
spamPrevention.reset();
};
/**
* This function ensures that Ghost's data is reset back to "factory settings"
*
*/
const resetData = async () => {
// Calling reset on the database also causes the fixtures to be re-run
// We need to unhook the settings events and restore the cache before we do this
// Otherwise, the fixtures being restored will refer to the old settings cache data
settingsService.reset();
// Clear out the database
await db.reset({truncate: true});
🔒 Prevented member creation when logging in (#15526) fixes https://github.com/TryGhost/Ghost/issues/14508 This change requires the frontend to send an explicit `emailType` when sending a magic link. We default to `subscribe` (`signin` for invite only sites) for now to remain compatible with the existing behaviour. **Problem:** When a member tries to login and that member doesn't exist, we created a new member in the past. - This caused the creation of duplicate accounts when members were guessing the email address they used. - This caused the creation of new accounts when using an old impersonation token, login link or email change link that was sent before member deletion. **Fixed:** - Trying to login with an email address that doesn't exist will throw an error now. - Added new and separate rate limiting to login (to prevent user enumeration). This rate limiting has a higher default limit of 8. I think it needs a higher default limit (because it is rate limited on every call instead of per email address. And it should be configurable independent from administrator rate limiting. It also needs a lower lifetime value because it is never reset. - Updated error responses in the `sendMagicLink` endpoint to use the default error encoding middleware. - The type (`signin`, `signup`, `updateEmail` or `subscribe`) is now stored in the magic link. This is used to prevent signups with a sign in token. **Notes:** - Between tests, we truncate the database, but this is not enough for the rate limits to be truly reset. I had to add a method to the spam prevention service to reset all the instances between tests. Not resetting them caused random failures because every login in every test was hitting those spam prevention middlewares and somehow left a trace of that in those instances (even when the brute table is reset). Maybe those instances were doing some in memory caching.
2022-10-05 13:42:42 +03:00
// Reset rate limiting instances (resetting the table is not enough!)
await resetRateLimits();
};
/**
* Creates a ContentAPITestAgent which is a drop-in substitution for supertest.
* It is automatically hooked up to the Content API so you can make requests to e.g.
* agent.get('/posts/') without having to worry about URL paths
* @returns {Promise<InstanceType<ContentAPITestAgent>>} agent
*/
const getContentAPIAgent = async () => {
try {
const app = await startGhost();
const originURL = configUtils.config.get('url');
return new ContentAPITestAgent(app, {
apiURL: '/ghost/api/content/',
originURL
});
} catch (error) {
error.message = `Unable to create test agent. ${error.message}`;
throw error;
}
};
/**
* Creates a AdminAPITestAgent which is a drop-in substitution for supertest.
* It is automatically hooked up to the Admin API so you can make requests to e.g.
* agent.get('/posts/') without having to worry about URL paths
*
* @param {Object} [options={}]
* @param {Boolean} [options.members] Include members in the boot process
* @returns {Promise<InstanceType<AdminAPITestAgent>>} agent
*/
const getAdminAPIAgent = async (options = {}) => {
const bootOptions = {};
if (options.members) {
bootOptions.frontend = true;
}
try {
const app = await startGhost(bootOptions);
const originURL = configUtils.config.get('url');
return new AdminAPITestAgent(app, {
apiURL: '/ghost/api/admin/',
originURL
});
} catch (error) {
error.message = `Unable to create test agent. ${error.message}`;
throw error;
}
};
/**
* Creates a MembersAPITestAgent which is a drop-in substitution for supertest
* It is automatically hooked up to the Members API so you can make requests to e.g.
* agent.get('/webhooks/stripe/') without having to worry about URL paths
*
* @returns {Promise<InstanceType<MembersAPITestAgent>>} agent
*/
const getMembersAPIAgent = async () => {
const bootOptions = {
frontend: true
};
try {
const app = await startGhost(bootOptions);
const originURL = configUtils.config.get('url');
return new MembersAPITestAgent(app, {
apiURL: '/members/',
originURL
});
} catch (error) {
error.message = `Unable to create test agent. ${error.message}`;
throw error;
}
};
/**
* Creates a MembersAPITestAgent which is a drop-in substitution for supertest
* It is automatically hooked up to the Members API so you can make requests to e.g.
* agent.get('/webhooks/stripe/') without having to worry about URL paths
*
* @returns {Promise<InstanceType<GhostAPITestAgent>>} agent
*/
const getWebmentionsAPIAgent = async () => {
const bootOptions = {
frontend: true
};
try {
const app = await startGhost(bootOptions);
const originURL = configUtils.config.get('url');
return new GhostAPITestAgent(app, {
apiURL: '/webmentions/',
originURL
});
} catch (error) {
error.message = `Unable to create test agent. ${error.message}`;
throw error;
}
};
/**
* Creates a GhostAPITestAgent, which is a drop-in substitution for supertest
* It is automatically hooked up to the Ghost API so you can make requests to e.g.
* agent.get('/well-known/jwks.json') without having to worry about URL paths
*
* @returns {Promise<InstanceType<GhostAPITestAgent>>} agent
*/
const getGhostAPIAgent = async () => {
const bootOptions = {
frontend: false
};
try {
const app = await startGhost(bootOptions);
const originURL = configUtils.config.get('url');
return new GhostAPITestAgent(app, {
apiURL: '/ghost/',
originURL
});
} catch (error) {
error.message = `Unable to create test agent. ${error.message}`;
throw error;
}
};
/**
*
* @returns {Promise<{adminAgent: InstanceType<AdminAPITestAgent>, membersAgent: InstanceType<MembersAPITestAgent>}>} agents
*/
const getAgentsForMembers = async () => {
let membersAgent;
let adminAgent;
const bootOptions = {
frontend: true
};
try {
const app = await startGhost(bootOptions);
const originURL = configUtils.config.get('url');
membersAgent = new MembersAPITestAgent(app, {
apiURL: '/members/',
originURL
});
adminAgent = new AdminAPITestAgent(app, {
apiURL: '/ghost/api/admin/',
originURL
});
} catch (error) {
error.message = `Unable to create test agent. ${error.message}`;
throw error;
}
return {
adminAgent,
membersAgent
};
};
/**
* WARNING: when using this, you should stop the returned ghostServer after the tests.
* @NOTE: for now method returns a supertest agent for Frontend instead of test agent with snapshot support.
Added a test suite for OPTIONS requests refs https://github.com/TryGhost/Toolbox/issues/461 - The codebase has ambiguous behavior with OPTIONS request. Adding tests covering edge cases for all possible variations of OPTIONS responses is the first step to solving cahceability of these requests. - The obvious question if you look into the changeset itself would also be: "WTF did you do with test suite naming? What are these changes in admin and click tracking suites? You having a bad day Naz?". The answer is "yes" (╯°□°)╯︵ ┻━┻ - On a serious note. I've introduced multiple hacks here that should be fixed: 1. Forced test suite execution order for options request - extreme blasphemy. This was last resort decision. I went deep into trying to fixup the server shutdown in the "admin" test suite, which cascaded into failing "click tracking" suite, which has shortcomings on it's own (see notes left in that suite) 2. Exposed "ghostServer" from the e2e-framework's "getAgentsWithFrontend" method. Exposing ghostServer to be able to shut it down (or do other manipulations) was one of the pitfalls we had in the previous test utils, which ended up plaguing the test codebase. Ideally the framework should only be exposing the agents and the rest would happen behind the scenes. - To fix the hacks above I've raised a cleanup issue (https://github.com/TryGhost/Toolbox/issues/471). I'm very sorry for this mess. The issue at hand has very little to do with fixing the e2e framework, so leaving things "as is".
2022-11-02 08:10:49 +03:00
* frontendAgent should be returning an instance of TestAgent (related: https://github.com/TryGhost/Toolbox/issues/471)
* @returns {Promise<{adminAgent: InstanceType<AdminAPITestAgent>, membersAgent: InstanceType<MembersAPITestAgent>, frontendAgent: InstanceType<supertest.SuperAgentTest>, contentAPIAgent: InstanceType<ContentAPITestAgent>, ghostServer: Express.Application}>} agents
*/
const getAgentsWithFrontend = async () => {
Added a test suite for OPTIONS requests refs https://github.com/TryGhost/Toolbox/issues/461 - The codebase has ambiguous behavior with OPTIONS request. Adding tests covering edge cases for all possible variations of OPTIONS responses is the first step to solving cahceability of these requests. - The obvious question if you look into the changeset itself would also be: "WTF did you do with test suite naming? What are these changes in admin and click tracking suites? You having a bad day Naz?". The answer is "yes" (╯°□°)╯︵ ┻━┻ - On a serious note. I've introduced multiple hacks here that should be fixed: 1. Forced test suite execution order for options request - extreme blasphemy. This was last resort decision. I went deep into trying to fixup the server shutdown in the "admin" test suite, which cascaded into failing "click tracking" suite, which has shortcomings on it's own (see notes left in that suite) 2. Exposed "ghostServer" from the e2e-framework's "getAgentsWithFrontend" method. Exposing ghostServer to be able to shut it down (or do other manipulations) was one of the pitfalls we had in the previous test utils, which ended up plaguing the test codebase. Ideally the framework should only be exposing the agents and the rest would happen behind the scenes. - To fix the hacks above I've raised a cleanup issue (https://github.com/TryGhost/Toolbox/issues/471). I'm very sorry for this mess. The issue at hand has very little to do with fixing the e2e framework, so leaving things "as is".
2022-11-02 08:10:49 +03:00
let ghostServer;
let membersAgent;
let adminAgent;
let frontendAgent;
let contentAPIAgent;
const bootOptions = {
frontend: true,
server: true
};
try {
Fixed configUtils and adapter cache issues in E2E tests (#16167) no issue There are a couple of issues with resetting the Ghost instance between E2E test files: These issues came to the surface because of new tests written in https://github.com/TryGhost/Ghost/pull/16117 **1. configUtils.restore does not work correctly** `config.reset()` is a callback based method. On top of that, it doesn't really work reliably (https://github.com/indexzero/nconf/issues/93) What kinda happens, is that you first call `config.reset` but immediately after you correcty reset the config using the `config.set` calls afterwards. But since `config.reset` is async, that reset will happen after all those sets, and the end result is that it isn't reset correctly. This mainly caused issues in the new updated images tests, which were updating the config `imageOptimization.contentImageSizes`, which is a deeply nested config value. Maybe some references to objects are reused in nconf that cause this issue? Wrapping `config.reset()` in a promise does fix the issue. **2. Adapters cache not reset between tests** At the start of each test, we set `paths:contentPath` to a nice new temporary directory. But if a previous test already requests a localStorage adapter, that adapter would have been created and in the constructor `paths:contentPath` would have been passed. That same instance will be reused in the next test run. So it won't read the new config again. To fix this, we need to reset the adapter instances between E2E tests. How was this visible? Test uploads were stored in the actual git repository, and not in a temporary directory. When writing the new image upload tests, this also resulted in unreliable test runs because some image names were already taken (from previous test runs). **3. Old 2E2 test Ghost server not stopped** Sometimes we still need access to the frontend test server using `getAgentsWithFrontend`. But that does start a new Ghost server which is actually listening for HTTP traffic. This could result in a fatal error in tests because the port is already in use. The issue is that old E2E tests also start a HTTP server, but they don't stop the server. When you used the old `startGhost` util, it would check if a server was already running and stop it first. The new `getAgentsWithFrontend` now also has the same functionality to fix that issue.
2023-01-30 16:06:20 +03:00
// Possible that we still have a running Ghost server from a previous old E2E test
// Those tests never stopped the server in the tests manually
await stopGhost();
// Start a new Ghost server with real HTTP listener
Added a test suite for OPTIONS requests refs https://github.com/TryGhost/Toolbox/issues/461 - The codebase has ambiguous behavior with OPTIONS request. Adding tests covering edge cases for all possible variations of OPTIONS responses is the first step to solving cahceability of these requests. - The obvious question if you look into the changeset itself would also be: "WTF did you do with test suite naming? What are these changes in admin and click tracking suites? You having a bad day Naz?". The answer is "yes" (╯°□°)╯︵ ┻━┻ - On a serious note. I've introduced multiple hacks here that should be fixed: 1. Forced test suite execution order for options request - extreme blasphemy. This was last resort decision. I went deep into trying to fixup the server shutdown in the "admin" test suite, which cascaded into failing "click tracking" suite, which has shortcomings on it's own (see notes left in that suite) 2. Exposed "ghostServer" from the e2e-framework's "getAgentsWithFrontend" method. Exposing ghostServer to be able to shut it down (or do other manipulations) was one of the pitfalls we had in the previous test utils, which ended up plaguing the test codebase. Ideally the framework should only be exposing the agents and the rest would happen behind the scenes. - To fix the hacks above I've raised a cleanup issue (https://github.com/TryGhost/Toolbox/issues/471). I'm very sorry for this mess. The issue at hand has very little to do with fixing the e2e framework, so leaving things "as is".
2022-11-02 08:10:49 +03:00
ghostServer = await startGhost(bootOptions);
const app = ghostServer.rootApp;
const originURL = configUtils.config.get('url');
membersAgent = new MembersAPITestAgent(app, {
apiURL: '/members/',
originURL
});
adminAgent = new AdminAPITestAgent(app, {
apiURL: '/ghost/api/admin/',
originURL
});
contentAPIAgent = new ContentAPITestAgent(app, {
apiURL: '/ghost/api/content/',
originURL
});
frontendAgent = supertest.agent(originURL);
} catch (error) {
error.message = `Unable to create test agent. ${error.message}`;
throw error;
}
return {
adminAgent,
membersAgent,
frontendAgent,
Added a test suite for OPTIONS requests refs https://github.com/TryGhost/Toolbox/issues/461 - The codebase has ambiguous behavior with OPTIONS request. Adding tests covering edge cases for all possible variations of OPTIONS responses is the first step to solving cahceability of these requests. - The obvious question if you look into the changeset itself would also be: "WTF did you do with test suite naming? What are these changes in admin and click tracking suites? You having a bad day Naz?". The answer is "yes" (╯°□°)╯︵ ┻━┻ - On a serious note. I've introduced multiple hacks here that should be fixed: 1. Forced test suite execution order for options request - extreme blasphemy. This was last resort decision. I went deep into trying to fixup the server shutdown in the "admin" test suite, which cascaded into failing "click tracking" suite, which has shortcomings on it's own (see notes left in that suite) 2. Exposed "ghostServer" from the e2e-framework's "getAgentsWithFrontend" method. Exposing ghostServer to be able to shut it down (or do other manipulations) was one of the pitfalls we had in the previous test utils, which ended up plaguing the test codebase. Ideally the framework should only be exposing the agents and the rest would happen behind the scenes. - To fix the hacks above I've raised a cleanup issue (https://github.com/TryGhost/Toolbox/issues/471). I'm very sorry for this mess. The issue at hand has very little to do with fixing the e2e framework, so leaving things "as is".
2022-11-02 08:10:49 +03:00
contentAPIAgent,
// @NOTE: ghost server should not be exposed ideally, it's a hack (see commit message)
ghostServer
};
};
const insertWebhook = ({event, url}) => {
return fixtureUtils.fixtures.insertWebhook({
event: event,
target_url: url
});
};
class Nullable extends AsymmetricMatcher {
constructor(sample) {
super(sample);
}
asymmetricMatch(other) {
if (other === null) {
return true;
}
return this.sample.asymmetricMatch(other);
}
toString() {
return `Nullable<${this.sample.toString()}>`;
}
getExpectedType() {
return `null|${this.sample.getExpectedType()}`;
}
toAsymmetricMatcher() {
return `Nullable<${this.sample.toAsymmetricMatcher ? this.sample.toAsymmetricMatcher() : this.sample.toString()}>`;
}
}
module.exports = {
// request agent
agentProvider: {
getAdminAPIAgent,
getMembersAPIAgent,
getWebmentionsAPIAgent,
getContentAPIAgent,
getAgentsForMembers,
getGhostAPIAgent,
getAgentsWithFrontend
},
// @NOTE: startGhost only exposed for playwright tests
startGhost,
// Mocks and Stubs
mockManager,
// DB State Manipulation
fixtureManager: {
get: getFixture,
insertWebhook: insertWebhook,
getCurrentOwnerUser: fixtureUtils.getCurrentOwnerUser,
init: initFixtures,
restore: resetData,
getPathForFixture: (fixturePath) => {
return path.join(__dirname, 'fixtures', fixturePath);
}
},
regexes: {
anyMajorMinorVersion: /v\d+\.\d+/gi,
queryStringToken: paramName => new RegExp(`${paramName}=(\\w|-)+`, 'g')
},
matchers: {
anyBoolean: any(Boolean),
anyString: any(String),
anyArray: any(Array),
anyObject: any(Object),
anyNumber: any(Number),
nullable: expectedObject => new Nullable(expectedObject), // usage: nullable(anyString)
anyStringNumber: stringMatching(/\d+/),
anyISODateTime: stringMatching(/\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.000Z/),
anyISODate: stringMatching(/\d{4}-\d{2}-\d{2}/),
anyISODateTimeWithTZ: stringMatching(/\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.000\+\d{2}:\d{2}/),
anyEtag: stringMatching(/(?:W\/)?"(?:[ !#-\x7E\x80-\xFF]*|\r\n[\t ]|\\.)*"/),
anyContentLength: stringMatching(/\d+/),
anyContentVersion: stringMatching(/v\d+\.\d+/),
anyObjectId: stringMatching(/[a-f0-9]{24}/),
anyErrorId: stringMatching(/[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}/),
anyUuid: stringMatching(/[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}/),
anyLocationFor: (resource) => {
return stringMatching(new RegExp(`https?://.*?/${resource}/[a-f0-9]{24}/`));
},
anyGhostAgent: stringMatching(/Ghost\/\d+\.\d+\.\d+\s\(https:\/\/github.com\/TryGhost\/Ghost\)/),
// @NOTE: hack here! it's due to https://github.com/TryGhost/Toolbox/issues/341
// this matcher should be removed once the issue is solved - routing is redesigned
// An ideal solution would be removal of this matcher altogether.
anyLocalURL: stringMatching(/http:\/\/127.0.0.1:2369\/[A-Za-z0-9_-]+\//),
stringMatching
},
// utilities
configUtils: require('./configUtils'),
dbUtils: require('./db-utils'),
🔒 Prevented member creation when logging in (#15526) fixes https://github.com/TryGhost/Ghost/issues/14508 This change requires the frontend to send an explicit `emailType` when sending a magic link. We default to `subscribe` (`signin` for invite only sites) for now to remain compatible with the existing behaviour. **Problem:** When a member tries to login and that member doesn't exist, we created a new member in the past. - This caused the creation of duplicate accounts when members were guessing the email address they used. - This caused the creation of new accounts when using an old impersonation token, login link or email change link that was sent before member deletion. **Fixed:** - Trying to login with an email address that doesn't exist will throw an error now. - Added new and separate rate limiting to login (to prevent user enumeration). This rate limiting has a higher default limit of 8. I think it needs a higher default limit (because it is rate limited on every call instead of per email address. And it should be configurable independent from administrator rate limiting. It also needs a lower lifetime value because it is never reset. - Updated error responses in the `sendMagicLink` endpoint to use the default error encoding middleware. - The type (`signin`, `signup`, `updateEmail` or `subscribe`) is now stored in the magic link. This is used to prevent signups with a sign in token. **Notes:** - Between tests, we truncate the database, but this is not enough for the rate limits to be truly reset. I had to add a method to the spam prevention service to reset all the instances between tests. Not resetting them caused random failures because every login in every test was hitting those spam prevention middlewares and somehow left a trace of that in those instances (even when the brute table is reset). Maybe those instances were doing some in memory caching.
2022-10-05 13:42:42 +03:00
urlUtils: require('./urlUtils'),
resetRateLimits
};