Merge branch 'master' into add-deprecation-policy

Author: mtrezza

.github/workflows/ci.yml

@@ -13,7 +13,7 @@ env:
 jobs:
   check-ci:
     name: CI Self-Check
-    timeout-minutes: 30
+    timeout-minutes: 15
     runs-on: ubuntu-18.04
     steps:
       - uses: actions/checkout@v2
@@ -32,6 +32,26 @@ jobs:
         run: npm ci
       - name: CI Self-Check
         run: npm run ci:check
+  check-lint:
+     name: Lint
+     timeout-minutes: 15
+     runs-on: ubuntu-18.04
+     steps:
+       - uses: actions/checkout@v2
+       - name: Use Node.js ${{ matrix.NODE_VERSION }}
+         uses: actions/setup-node@v1
+         with:
+           node-version: ${{ matrix.node-version }}
+       - name: Cache Node.js modules
+         uses: actions/cache@v2
+         with:
+           path: ~/.npm
+           key: ${{ runner.os }}-node-${{ matrix.NODE_VERSION }}-${{ hashFiles('**/package-lock.json') }}
+           restore-keys: |
+             ${{ runner.os }}-node-${{ matrix.NODE_VERSION }}-
+       - name: Install dependencies
+         run: npm ci
+       - run: npm run lint
   check-mongo:
     strategy:
       matrix:
@@ -40,45 +60,46 @@ jobs:
             MONGODB_VERSION: 4.4.4
             MONGODB_TOPOLOGY: replicaset
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 14.15.5
+            NODE_VERSION: 14.16.0
           - name: Mongo 4.2, ReplicaSet, WiredTiger
-            MONGODB_VERSION: 4.2.12
+            MONGODB_VERSION: 4.2.13
             MONGODB_TOPOLOGY: replicaset
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 14.15.5
+            NODE_VERSION: 14.16.0
           - name: Mongo 4.0, ReplicaSet, WiredTiger
             MONGODB_VERSION: 4.0.23
             MONGODB_TOPOLOGY: replicaset
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 14.15.5
+            NODE_VERSION: 14.16.0
           - name: Mongo 3.6, Standalone, MMAPv1
-            MONGODB_VERSION: 3.6.22
+            MONGODB_VERSION: 3.6.23
             MONGODB_TOPOLOGY: standalone
             MONGODB_STORAGE_ENGINE: mmapv1
-            NODE_VERSION: 14.15.5
+            NODE_VERSION: 14.16.0
           - name: Redis Cache
             PARSE_SERVER_TEST_CACHE: redis
             MONGODB_VERSION: 4.4.4
             MONGODB_TOPOLOGY: standalone
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 14.15.5
+            NODE_VERSION: 14.16.0
           - name: Node 10
             MONGODB_VERSION: 4.4.4
             MONGODB_TOPOLOGY: standalone
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 10.23.3
+            NODE_VERSION: 10.24.0
           - name: Node 12
             MONGODB_VERSION: 4.4.4
             MONGODB_TOPOLOGY: standalone
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 12.20.2
+            NODE_VERSION: 12.21.0
           - name: Node 15
             MONGODB_VERSION: 4.4.4
             MONGODB_TOPOLOGY: standalone
             MONGODB_STORAGE_ENGINE: wiredTiger
-            NODE_VERSION: 15.9.0
+            NODE_VERSION: 15.12.0
+      fail-fast: false
     name: ${{ matrix.name }}
-    timeout-minutes: 30
+    timeout-minutes: 15
     runs-on: ubuntu-18.04
     services:
       redis:
@@ -106,8 +127,6 @@ jobs:
             ${{ runner.os }}-node-${{ matrix.NODE_VERSION }}-
       - name: Install dependencies
         run: npm ci
-      - if: ${{ matrix.name == 'Mongo 3.6.21' }}
-        run: npm run lint
       - run: npm run pretest
       - run: npm run coverage
         env:
@@ -127,8 +146,9 @@ jobs:
             POSTGRES_IMAGE: postgis/postgis:12-3.0
           - name: Postgres 13, Postgis 3.1
             POSTGRES_IMAGE: postgis/postgis:13-3.1
+      fail-fast: false
     name: ${{ matrix.name }}
-    timeout-minutes: 30
+    timeout-minutes: 15
     runs-on: ubuntu-18.04
     services:
       redis:

CHANGELOG.md

@@ -15,6 +15,8 @@
   - [Deprecation Policy](#deprecation-policy)
 - [Feature Considerations](#feature-considerations)
   - [Security Checks](#security-checks)
+    - [Add Security Check](#add-security-check)
+    - [Wording Guideline](#wording-guideline)
   - [Parse Error](#parse-error)
   - [Parse Server Configuration](#parse-server-configuration)
 - [Code of Conduct](#code-of-conduct)
@@ -84,6 +86,14 @@ Once you have babel running in watch mode, you can start making changes to parse
 * All the tests should point to sources in the `lib/` folder.
 * The `lib/` folder is produced by `babel` using either the `npm run build`, `npm run watch`, or the `npm run prepare` step.
 * The `npm run prepare` step is automatically invoked when your package depends on forked parse-server installed via git for example using `npm install --save git+https://github.com/[username]/parse-server#[branch/commit]`.
+* The tests are run against a single server instance. You can change the server configurations using `await reconfigureServer({ ... some configuration })` found in `spec/helper.js`.
+* The tests are ran at random.
+* Caches and Configurations are reset after every test.
+* Users are logged out after every test.
+* Cloud Code hooks are removed after every test.
+* Database is deleted after every test (indexes are not removed for speed)
+* Tests are located in the `spec` folder
+* For better test reporting enable `PARSE_SERVER_LOG_LEVEL=debug`
 
 ### Troubleshooting
 
@@ -108,13 +118,14 @@ Once you have babel running in watch mode, you can start making changes to parse
 * Run the tests for the whole project to make sure the code passes all tests. This can be done by running the test command for a single file but removing the test file argument. The results can be seen at *<PROJECT_ROOT>/coverage/lcov-report/index.html*.
 * Lint your code by running `npm run lint` to make sure the code is not going to be rejected by the CI.
 * **Do not** publish the *lib* folder.
+* Mocks belong in the `spec/support` folder.
 * Please consider if any changes to the [docs](http://docs.parseplatform.org) are needed or add additional sections in the case of an enhancement or feature.
 
 ### Test against Postgres
 
 If your pull request introduces a change that may affect the storage or retrieval of objects, you may want to make sure it plays nice with Postgres.
 
-* Run the tests against the postgres database with `PARSE_SERVER_TEST_DB=postgres PARSE_SERVER_TEST_DATABASE_URI=postgres://postgres:password@localhost:5432/parse_server_postgres_adapter_test_database npm run testonly`. You'll need to have postgres running on your machine and setup [appropriately](https://github.com/parse-community/parse-server/blob/master/.travis.yml#L43) or use [`Docker`](#run-a-parse-postgres-with-docker).
+* Run the tests against the postgres database with `PARSE_SERVER_TEST_DB=postgres PARSE_SERVER_TEST_DATABASE_URI=postgres://postgres:password@localhost:5432/parse_server_postgres_adapter_test_database npm run testonly`. You'll need to have postgres running on your machine and setup [appropriately](https://github.com/parse-community/parse-server/blob/master/scripts/before_script_postgres.sh) or use [`Docker`](#run-a-parse-postgres-with-docker).
 * The Postgres adapter has a special debugger that traces all the sql commands. You can enable it with setting the environment variable `PARSE_SERVER_LOG_LEVEL=debug`
 * If your feature is intended to only work with MongoDB, you should disable PostgreSQL-specific tests with:
 
@@ -137,7 +148,7 @@ If your pull request introduces a change that may affect the storage or retrieva
 [PostGIS images (select one with v2.2 or higher) on docker dashboard](https://hub.docker.com/r/postgis/postgis) is based off of the official [postgres](https://registry.hub.docker.com/_/postgres/) image and will work out-of-the-box (as long as you create a user with the necessary extensions for each of your Parse databases; see below). To launch the compatible Postgres instance, copy and paste the following line into your shell:
 
 ```
-docker run -d --name parse-postgres -p 5432:5432 -e POSTGRES_PASSWORD=password --rm postgis/postgis:11-3.0-alpine && sleep 20 && docker exec -it parse-postgres psql -U postgres -c 'CREATE DATABASE parse_server_postgres_adapter_test_database;' && docker exec -it parse-postgres psql -U postgres -c 'CREATE EXTENSION postgis;' -d parse_server_postgres_adapter_test_database && docker exec -it parse-postgres psql -U postgres -c 'CREATE EXTENSION postgis_topology;' -d parse_server_postgres_adapter_test_database
+docker run -d --name parse-postgres -p 5432:5432 -e POSTGRES_PASSWORD=password --rm postgis/postgis:11-3.0-alpine && sleep 20 && docker exec -it parse-postgres psql -U postgres -c 'CREATE DATABASE parse_server_postgres_adapter_test_database;' && docker exec -it parse-postgres psql -U postgres -c 'CREATE EXTENSION pgcrypto; CREATE EXTENSION postgis;' -d parse_server_postgres_adapter_test_database && docker exec -it parse-postgres psql -U postgres -c 'CREATE EXTENSION postgis_topology;' -d parse_server_postgres_adapter_test_database
 ```
 To stop the Postgres instance:
 
@@ -189,13 +200,61 @@ A security check needs to be added for every new feature or enhancement that all
 
 For example, allowing public read and write to a class may be useful to simplify development but should be disallowed in a production environment.
 
-Security checks are added in [SecurityChecks.js](https://github.com/parse-community/parse-server/blob/master/src/SecurityChecks.js).
+Security checks are added in [CheckGroups](https://github.com/parse-community/parse-server/tree/master/src/Security/CheckGroups).
+
+#### Add Security Check
+Adding a new security check for your feature is easy and fast:
+1. Look into [CheckGroups](https://github.com/parse-community/parse-server/tree/master/src/Security/CheckGroups) whether there is an existing `CheckGroup[Category].js` file for the category of check to add. For example, a check regarding the database connection is added to `CheckGroupDatabase.js`.
+2. If you did not find a file, duplicate an existing file and replace the category name in `setName()` and the checks in `setChecks()`:
+    ```js
+    class CheckGroupNewCategory extends CheckGroup {
+      setName() {
+        return 'House';
+      }
+      setChecks() {
+        return [
+          new Check({
+            title: 'Door locked',
+            warning: 'Anyone can enter your house.',
+            solution: 'Lock the door.',
+            check: () => {    
+              return;     // Example of a passing check
+            }
+          }),
+          new Check({
+            title: 'Camera online',
+            warning: 'Security camera is offline.',
+            solution: 'Check the camera.',
+            check: async () => {  
+              throw 1;     // Example of a failing check
+            }
+          }),
+        ];
+      }
+    }
+    ```
+
+3. If you added a new file in the previous step, reference the file in [CheckGroups.js](https://github.com/parse-community/parse-server/blob/master/src/Security/CheckGroups/CheckGroups.js), which is the collector of all security checks:
+    ```
+    export { default as CheckGroupNewCategory } from './CheckGroupNewCategory';
+    ```
+4. Add a test that covers the new check to [SecurityCheckGroups.js](https://github.com/parse-community/parse-server/blob/master/spec/SecurityCheckGroups.js) for the cases of success and failure.
+
+#### Wording Guideline
+Consider the following when adding a new security check:
+- *Group.name*: The category name; ends without period as this is a headline.
+- *Check.title*: Is the positive hypothesis that should be checked, for example "Door locked" instead of "Door unlocked"; ends without period as this is a title.
+- *Check.warning*: The warning if the test fails; ends with period as this is a description.
+- *Check.solution*: The recommended solution if the test fails; ends with period as this is an instruction.
+- The wordings must not contain any sensitive information such as keys, as the security report may be exposed in logs.
+- The wordings should be concise and not contain verbose explanations, for example "Door locked" instead of "Door has been locked securely".
+- Do not use pronouns such as "you" or "your" because log files can have various readers with different roles. Do not use pronouns such as "I" or "me" because although we love it dearly, Parse Server is not a human.
 
 ### Parse Error
 
 Introducing new Parse Errors requires the following steps:
 
-1. Research whether an existing Parse Error already covers the error scenario. Keep in mind that reusing an already existing Parse Error does not allow to distinguish between scenarios in which the same error is thrown, so it may be necessary to add a new and more specific Parse Error, eventhough an more general Parse Error already exists.
+1. Research whether an existing Parse Error already covers the error scenario. Keep in mind that reusing an already existing Parse Error does not allow to distinguish between scenarios in which the same error is thrown, so it may be necessary to add a new and more specific Parse Error, even though a more general Parse Error already exists.
 ⚠️ Currently (as of Dec. 2020), there are inconsistencies between the Parse Errors documented in the Parse Guides, coded in the Parse JS SDK and coded in Parse Server, therefore research regarding the availability of error codes has to be conducted in all of these sources.
 1. Add the new Parse Error to [/src/ParseError.js](https://github.com/parse-community/Parse-SDK-JS/blob/master/src/ParseError.js) in the Parse JavaScript SDK. This is the primary reference for Parse Errors for the Parse JavaScript SDK and Parse Server.
 1. Create a pull request for the Parse JavaScript SDK including the new Parse Errors. The PR needs to be merged and a new Parse JS SDK version needs to be released.