You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Parse Server 6 Migration Guide <!-- omit in toc -->
2
+
3
+
This document only highlights specific changes that require a longer explanation. For a full list of changes in Parse Server 6 please refer to the [changelog](https://github.com/parse-community/parse-server/blob/alpha/CHANGELOG.md).
The import and initialization syntax has been simplified with more intuitive naming and structure.
15
+
16
+
*Parse Server 5:*
17
+
```js
18
+
// Returns a Parse Server instance
19
+
constParseServer=require('parse-server');
20
+
21
+
// Returns a Parse Server express middleware
22
+
const { ParseServer } =require('parse-server');
23
+
```
24
+
25
+
*Parse Server 6:*
26
+
```js
27
+
// Both return a Parse Server instance
28
+
constParseServer=require('parse-server');
29
+
const { ParseServer } =require('parse-server');
30
+
```
31
+
32
+
To get the express middleware in Parse Server 6, configure the Parse Server instance, start Parse Server and use its `app` property. See [Asynchronous Initialization](#asynchronous-initialization) for more details.
33
+
34
+
## Asynchronous Initialization
35
+
36
+
Previously, it was possible to mount Parse Server before it was fully started up and ready to receive requests. This could result in undefined behavior, such as Parse Objects could be saved before Cloud Code was registered. To prevent this, Parse Server 6 requires to be started asynchronously before being mounted.
37
+
38
+
*Parse Server 5:*
39
+
```js
40
+
// 1. Import Parse Server
41
+
const { ParseServer } =require('parse-server');
42
+
43
+
// 2. Create a Parse Server instance as express middleware
@@ -451,6 +452,24 @@ If the commit reverts a previous commit, use the prefix `revert:`, followed by t
451
452
This reverts commit 1234567890abcdef.
452
453
```
453
454
455
+
### Security Vulnerability
456
+
457
+
#### Local Testing
458
+
459
+
Fixes for securify vulnerabilities are developed in private forks with a closed audience, inaccessible to the public. A current GitHub limitation does not allow to run CI tests on pull requests in private forks. Whether a pull requests fully passes all CI tests can only be determined by publishing the fix as a public pull request and running the CI. This means the fix and implicitly information about the vulnerabilty are made accessible to the public. This increases the risk that a vulnerability fix is published, but then cannot be merged immediately due to a CI issue. To mitigate that risk, before publishing a vulnerability fix, the following tests needs to be run locally and pass:
460
+
461
+
- `npm run test` (MongoDB)
462
+
- `npm run test` (Postgres)
463
+
- `npm run madge:circular` (circular dependencies)
464
+
- `npm run lint` (Lint)
465
+
- `npm run definitions` (Parse Server options definitions)
466
+
467
+
#### Merging
468
+
469
+
A current GitHub limitation does not allow to customize the commit message when merging pull requests of a private fork that was created to fix a security vulnerabilty. Our release automation framework demands a specific commit message syntax which therefore cannot be met. This prohibits to follow the process that GitHub suggest, which is to merge a pull request from a private fork directly to a public branch. Instead, after [local testing](#local-testing), a public pull request needs to be created with the code fix copied over from the private pull request.
470
+
471
+
This creates a risk that a vulnerability is indirectly disclosed by publishing a pull request with the fix, but the fix cannot be merged due to a CI issue. To mitigate that risk, the pull request title and description should be kept marginal or generic, not hiting to a vulnerabilty or giving any details about the vulnerabilty, until the pull request has been successfully merged.
Copy file name to clipboardExpand all lines: README.md
+42-15Lines changed: 42 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,7 +40,7 @@ A big *thank you* 🙏 to our [sponsors](#sponsors) and [backers](#backers) who
40
40
41
41
---
42
42
43
-
-[Flavors & Branches](#flavors--branches)
43
+
-[Flavors \& Branches](#flavors--branches)
44
44
-[Long Term Support](#long-term-support)
45
45
-[Getting Started](#getting-started)
46
46
-[Running Parse Server](#running-parse-server)
@@ -55,6 +55,8 @@ A big *thank you* 🙏 to our [sponsors](#sponsors) and [backers](#backers) who
55
55
-[Running Parse Server elsewhere](#running-parse-server-elsewhere)
56
56
-[Sample Application](#sample-application)
57
57
-[Parse Server + Express](#parse-server--express)
58
+
-[Parse Server Health](#parse-server-health)
59
+
-[Status Values](#status-values)
58
60
-[Configuration](#configuration)
59
61
-[Basic Options](#basic-options)
60
62
-[Client Key Options](#client-key-options)
@@ -136,13 +138,13 @@ Parse Server is continuously tested with the most recent releases of Node.js to
136
138
137
139
Parse Server is continuously tested with the most recent releases of MongoDB to ensure compatibility. We follow the [MongoDB support schedule](https://www.mongodb.com/support-policy) and [MongoDB lifecycle schedule](https://www.mongodb.com/support-policy/lifecycles) and only test against versions that are officially supported and have not reached their end-of-life date. We consider the end-of-life date of a MongoDB "rapid release" to be the same as its major version release.
138
140
139
-
| Version | Latest Version | End-of-Life | Compatible |
For a full list of available options, run `parse-server --help` or take a look at [Parse Server Configurations](http://parseplatform.org/parse-server/api/master/ParseServerOptions.html).
307
312
313
+
## Parse Server Health
314
+
315
+
Check the Parse Server health by sending a request to the `/parse/health` endpoint.
|`initialized`| The server has been created but the `start` method has not been called yet. |
330
+
|`starting`| The server is starting up. |
331
+
|`ok`| The server started and is running. |
332
+
|`error`| There was a startup error, see the logs for details. |
333
+
308
334
# Configuration
309
335
310
336
Parse Server can be configured using the following options. You may pass these as parameters when running a standalone `parse-server`, or by loading a configuration file in JSON format using `parse-server path/to/configuration.json`. If you're using Parse Server on Express, you may also pass these to the `ParseServer` object as options.
@@ -461,7 +487,7 @@ The following paths are already used by Parse Server's built-in features and are
461
487
It’s possible to change the default pages of the app and redirect the user to another path or domain.
462
488
463
489
```js
464
-
var server = ParseServer({
490
+
const server = ParseServer({
465
491
...otherOptions,
466
492
467
493
customPages: {
@@ -851,7 +877,7 @@ Then, create an `index.js` file with the following content:
* Asynchronous initialization of Parse Server ([#8232](https://github.com/parse-community/parse-server/issues/8232)) ([99fcf45](https://github.com/parse-community/parse-server/commit/99fcf45e55c368de2345b0c4d780e70e0adf0e15))
7
+
8
+
9
+
### BREAKING CHANGES
10
+
11
+
* This release introduces the asynchronous initialization of Parse Server to prevent mounting Parse Server before being ready to receive request; it changes how Parse Server is imported, initialized and started; it also removes the callback `serverStartComplete`; see the [Parse Server 6 migration guide](https://github.com/parse-community/parse-server/blob/alpha/6.0.0.md) for more details (#8232) ([99fcf45](99fcf45))
* Nested objects are encoded incorrectly for MongoDB ([#8209](https://github.com/parse-community/parse-server/issues/8209)) ([1412666](https://github.com/parse-community/parse-server/commit/1412666f75829612de6fb9d7ccae35761c9b75cb))
19
+
20
+
21
+
### BREAKING CHANGES
22
+
23
+
* Nested objects are now properly stored in the database using JSON serialization; previously, due to a bug only top-level objects were serialized, but nested objects were saved as raw JSON; for example, a nested `Date` object was saved as a JSON object like `{ "__type": "Date", "iso": "2020-01-01T00:00:00.000Z" }` instead of its serialized representation `2020-01-01T00:00:00.000Z` (#8209) ([1412666](1412666))
* Write log entry when request with master key is rejected as outside of `masterKeyIps` ([#8350](https://github.com/parse-community/parse-server/issues/8350)) ([e22b73d](https://github.com/parse-community/parse-server/commit/e22b73d4b700c8ff745aa81726c6680082294b45))
* Add option to change the log level of the logs emitted by triggers ([#8328](https://github.com/parse-community/parse-server/issues/8328)) ([8f3b694](https://github.com/parse-community/parse-server/commit/8f3b694e39d4a966567e50dbea4d62e954fa5c06))
'Definitions files cannot be updated manually. Please update src/Options/index.js then run `npm run definitions` to generate definitions.'
33
+
);
34
+
core.error('Definitions files cannot be updated manually. Please update src/Options/index.js then run `npm run definitions` to generate definitions.');
0 commit comments