BREAKING CHANGE: The MongoDB GridStore adapter has been removed. By default, Parse Server already uses GridFS, so if you do not manually use the GridStore adapter, you can ignore this change.
BREAKING CHANGE: To delete a field via the GraphQL API, the field value has to be set to `null`. Previously, setting a field value to `null` would save a null value in the database, which was not according to the [GraphQL specs](https://spec.graphql.org/June2018/#sec-Null-Value). To delete a file field use `file: null`, the previous way of using `file: { file: null }` has become obsolete.
* Added a test case that triggers the query parameter crash
* rest.js: validate the explain parameter to keep the nodejs driver from throwing an uncatchable exception and crashing the server (see https://jira.mongodb.org/browse/NODE-3463)
RestQuery.js: Check whether explain mode is enabled not by "!== true", but by the "!" operator. explain can have string values.
Added tests that validate correct behaviour on different explain values
* Refactor the new tests
* Simplify the new tests
Also do a sanity check on the explain results
* Test refactor
* Exclude queryPlannerExtended as it is not supported by the testing environment
Simplifies the tests
* Restrict the changes to mongodb
Moved the verification of the explain value from rest.js to MongoStorageAdapter.js
Also restricted the relevant unit tests to mongodb
* Added changelog entry
* reformat changelog entry
* Update CHANGELOG.md
Co-authored-by: Kartal Kaan Bozdoğan <kartalkaanbozdogan@gmail.com>
Co-authored-by: Manuel <5673677+mtrezza@users.noreply.github.com>
* failing testcase
* add header
* switch to X-Parse-Cloud-Context header
* add back blank line that lint removed
* test replacing context header with body context. Add support for setting body with json string
* add back blank line
* cover error when _context body is wrong
* Update middlewares.js
* revert accidental status change
* make sure context always decodes to an object else throw error
* improve context object check
Co-authored-by: Antonio Davi Macedo Coelho de Castro <adavimacedo@gmail.com>
* 6641: Implement support for user impersonation: master key clients can log in as any user, without access to the user's credentials, and without presuming the user already has a session
* reworded changelog
* rebuilt package lock
* fit test
* using lodash flatMap
* bump to node 12 for postgres test
* revert test fit
* add node version to postgres CI
* revert package-lock
Co-authored-by: gormanfletcher <git@gormanfletcher.com>
Co-authored-by: Manuel <5673677+mtrezza@users.noreply.github.com>
* fix keys and excludeKeys to work with JSON array strings
* make excludeKeys test more robust
* add changelog
* add select([]) functionality to fix)
* update changelog
* update keys
* add exclude test
* add select REST test and exclude JS SDK test
* add more tests
* add additional exclude test
* improved select test for testing JSON string array in REST
* improved exclude test for testing JSON string array in REST
* check for parse keys
* make include look like keys and excludeKeys
* nit
* Exclude nexted child fields
* add updates and show failing testcases
* working
* add more tests
* even more test cases
* use await for added tests
* lint
* Add suggestions
* Fixed a bug affecting updates to nested pointers
Also created unit tests
* Marked the regression test for #7391 as pending for postgre
The issue is not fixed yet
Use cont instead of var
* Only check the type of a parameter in the validator when the parameter is set to required or is not null
* Added test cases. Don't check type or options if required=false and no default value is set
* Added test cases. Don't check type or options if required=false and no default value is set
* Update const optional
* Add a failing test for issue #7340
If any delay occurs after "message.event" assignation in
LiveQueryServer._onAfterSave, the next subscription or request with a different
event might overwrite it, and by that using the wrong "push" function name.
* Remove updade of message and use res.event instead
This prevent computing function name from a
incorrect event if multiple subscriptions override
one by one the message.event.
* Update CHANGELOG.md
* Replace setTimeout by async/await expressions
* Add lock file version check to CI
* Update CHANGELOG.md
* Update ci.yml
* test failing check with lock file version 2
* Revert "test failing check with lock file version 2"
This reverts commit a5b4293f31.
* fix: upgrade mongodb from 3.6.3 to 3.6.5
Snyk has created this PR to upgrade mongodb from 3.6.3 to 3.6.5.
See this package in npm:
https://www.npmjs.com/package/mongodb
See this project in Snyk:
https://app.snyk.io/org/acinader/project/8c1a9edb-c8f5-4dc1-b221-4d6030a323eb?utm_source=github&utm_medium=upgrade-pr
* bump mongo 3.6.6
* update package-lock
* updated package-lock
* fix: upgrade winston-daily-rotate-file from 4.5.0 to 4.5.1 (#7309)
Snyk has created this PR to upgrade winston-daily-rotate-file from 4.5.0 to 4.5.1.
See this package in npm:
https://www.npmjs.com/package/winston-daily-rotate-file
See this project in Snyk:
https://app.snyk.io/org/acinader/project/8c1a9edb-c8f5-4dc1-b221-4d6030a323eb?utm_source=github&utm_medium=upgrade-pr
* Bump CI environment, remove Postgres 10 support (#7323)
* bumped MongoDB to 4.4.5
* bump Node to 14.16.1
* removed obsolete COVERAGE_OPTION
* improved postges support note
* bump more node
* Remove MongoDB 3.6 support (EOL) (#7315)
* removed mongodb 3.6 support
* add changelog entry
* updated CI check
* bumped MongoDB to 4.4.5
* bump Node to 14.16.1
* removed obsolete COVERAGE_OPTION
* improved postges support note
* bump more node
* updated package lock
* Revert "bumped MongoDB to 4.4.5"
This reverts commit ce9c8108c3.
* skipping MongoDB 4.4.5 temporarily
* fixed bug in CI check that did not consider ignored versions when checking for newer versions
* removed Postgres 10 support
* updated Postgres versions
* renamed MongoDB CI tests
* fixed Postgres compatibility table
* fix Postgres badge
* Add deprecation policy (#7199)
* added phased deprecation policy
* fixed typo
* added changelog entry
* some rewording
* Fixed typo
* fixed typo
* Fixed typo
* updated deprecation policy
* remove empty line
* fix: upgrade mongodb from 3.6.3 to 3.6.5
Snyk has created this PR to upgrade mongodb from 3.6.3 to 3.6.5.
See this package in npm:
https://www.npmjs.com/package/mongodb
See this project in Snyk:
https://app.snyk.io/org/acinader/project/8c1a9edb-c8f5-4dc1-b221-4d6030a323eb?utm_source=github&utm_medium=upgrade-pr
* bump mongo 3.6.6
* Update package-lock.json
Co-authored-by: Manuel Trezza <5673677+mtrezza@users.noreply.github.com>
* enabled direct access by default
* removed obsolete direct access option test case
* quick fix test
* Set RESTController during tests
* Properly handle RESTController
* Documentation
* revert changes
* rerun tests
* remove extra parse instance
* Revert "remove extra parse instance"
This reverts commit 21422f45f1.
* Ensure restcontroller is set
* Fix test
* improved option docs
* renamed direct access env var
* added deprecations to README
* added deprecation definition
* fixed docs typo
* improve promise rejection warning test
* added renaming of env var to deprecation warning
Co-authored-by: Diamond Lewis <findlewis@gmail.com>
* fix: empty file tags cause upload error for some providers
DigitalOcean and Linode object storage solutions do not accept `tags` option while uploading a file. Previously, tags option was set to default empty object. Now, we do not include it if it is empty.
* chore: add tests for saving a file with/without tags
* chore: update file tags handling to make tests pass
* chore: refactor file tag tests
* chore: update file tag tests
* chore: update changelog
* chore: update changelog entry
* chore: remove duplicated changelog entry
* Use Node.js 15.13.0 in CI
* CI: Allow check-postgres 20 timeout
* CI: 30 min timeout for check-postgres
* reverted postgres timeout to 15
Co-authored-by: Manuel <5673677+mtrezza@users.noreply.github.com>
* renamed "resetPassword" to "requestResetPassword" & created new "resetPassword" mutation
* added new route to handle resetPassword in UsersRouter.js
* updated resetPassword test to "requestResetPassword" mutation
* updated "resetPassword" mutation args description
* changed token arg description to rerun the tests
* directly using updatePassword for resetPassword
* removed handleResetPassword from UsersRouter.js file
* added test case for reset Password
* changed mutation names to "resetPassword" & "confirmResetPassword"
* changed mutation names in test also
* Excluding keys that have trailing "edges.node" on them as they will not be selectable anyway
* Updated CHANGELOG and added test case
* Forgot to change fit back to it
* add search for atlas search index
* added test for search in pipeline
* removed stage name check in pipeline
* removed spec for invalid query invalid key
* updated changelog
Co-authored-by: Diamond Lewis <findlewis@gmail.com>
* Fix flaky postgres test
* add pgcrypto extension to test
* fix postgres ref link CONTRIBUTING guide and add pgcrypto extension
* Update CONTRIBUTING.md
* new: allow options to be async on Cloud Validator
* Update CHANGELOG.md
* Ensure pushStatus is properly running (#7213)
* Ensure pushStatus is properly running
* remove duplicate test
* new: allow options to be async on Cloud Validator
* Update CHANGELOG.md
* Update CloudCode.Validator.spec.js
Co-authored-by: Diamond Lewis <findlewis@gmail.com>
* Increase timeout for redis tests
* Remove for
* Increase little bit more one of the tests since it requires two calls to be done in time-fahsion way
* increase default ttl a bit more
* Fix for authenticating with instagram
* Change tests for instagram authentication
* Instagram authentication for the case when data child object is presented in the response
* Fix error when a not yet inserted job is updated
* Add entry to changelog
* revert the upsert change and fix the test
* Revert the change so job execute a single time
* Fix other tests with potential similar problem
* Fix flaky test with transactions
* Add CHANGELOG entry
* Fix the other transactions related tests that became flaky because now Parse Server tries to submit the transaction multilpe times in the case of TransientError
* Remove fit from tests
* added localized pages; added refactored page templates; adapted test cases; introduced localization test cases
* added changelog entry
* fixed test description typo
* fixed bug in PromiseRouter where headers are not added for text reponse
* added page parameters in page headers for programmatic use
* refactored tests for PublicAPIRouter
* added mustache lib for template rendering
* fixed fs.promises module reference
* fixed template placeholder typo
* changed redirect response to provide headers instead of query parameters
* fix lint
* fixed syntax errors and typos in html templates
* removed obsolete URI encoding
* added locale inferring from request body and header
* added end-to-end localizaton test
* added server option validation; refactored pages server option
* fixed invalid redirect URL for no locale matching file
* added end-to-end localizaton tests
* adapted tests to new response content
* re-added PublicAPIRouter; added PagesRouter as experimental feature
* refactored PagesRouter test structure
* added configuration option for custom path to pages
* added configuration option for custom endpoint to pages
* fixed lint
* added tests
* added a distinct page for invalid password reset link
* renamed generic page invalidLink to expiredVerificationLink
* improved HTML files documentation
* improved HTML files documentation
* changed changelog entry for experimental feature
* improved file naming to make it more descriptive
* fixed file naming and env parameter naming
* added readme entry
* fixed readme TOC - hasn't been updated in a while
* added localization with JSON resource
* added JSON localization to feature pages (password reset, email verification)
* updated readme
* updated readme
* optimized JSON localization for feature pages; added e2e test case
* fixed readme typo
* minor refactoring of existing tests
* fixed bug where Object type was not recognized as config key type
* added feature config placeholders
* prettier
* added passing locale to page config placeholder callback
* refactored passing locale to placeholder to pass test
* added config placeholder feature to README
* fixed typo in README
* added tests environment with mongodb 4.4.3
* added CI test for mongodb 4.4.3
* added CI tests for MongoDB versions 4.0, 4.2
* improved flaky test (seems to max out the limit of simultaneous connections)
* added spec helpers to run tests only for specific MongoDB version
* addedn npm scripts to run tests against relevant mongodb versions
* added spec helper function to exclude specific mongodb version
* added test for changed aggregate query planner results
* fixed regex test with incorrect regex syntax
* fixed test where query has select no keys (empty array)
* added changelog entry and ordered list
* fixed test that tried to simultaneously delete and build index on same collection
* added MongoDB compatibility table to readme
* updated default local tests to use MongoDB 4.4.3
* added MongoDB badges for new versions to README
* fixed typo in readme
* added new test helper filter to contribution guide
* fixed incorrect storage engine for mongodb 4.4
* changed CI to test MongoDB 3.6. with mmapv1 storage engine and standalone
* improved CI test description
* added CI self check for new MongoDB versions
* fixed CI
* removed CI
* added CI
* added throwing error if any of the checks failed
* added github action connector
* improved error message
* improved error messages
* improved error message
* updated CI environment to MongoDB 3.6.22
* improved error messages
* update CI env name
* updated CI env name
* improved error message
* removed patch versions from CI env description
* improved status message
* removed version range from core lib
* added explicit mongodb version to redis test and node 12 test
* bumped Node 12 test to 12.20.1 (version currently recommended by AWS Elastic Beanstalk)
* Add Test case for checking SchemaCacheTTL
* Fix schemaCacheTTL not working issue
* Add Test case for TTL expires
Co-authored-by: Roach Chang <roach.chang@aoitek.com>
* Parse LiveQuery Server. Supporting patterns in classNames.
* Parse LiveQuery Server. Supporting patterns in classNames. Small optimisation.
* Parse LiveQuery Server. Supporting patterns in classNames. Adding info to changelog.
* Parse LiveQuery Server. Supporting patterns in classNames. Test case.
* added fileUpload definition default value
* added undefined and null as invalid
* removed explicit default value reference
* improved test grouping in describes
* Optimize redundant logic used in queries
* Added CHANGELOG
* Fixed comments and code style after recommendations.
* Fixed code style after recommendation.
* Improved explanation in comments
* Added tests to for logic optimizations
* Added two test cases more and some comments
* Added extra test cases and fixed issue found with them.
* Removed empty lines as requested.
Co-authored-by: Pedro Diaz <p.diaz@wemersive.com>
* improved feature suggestion template
* added test case chapter to bug report template
* PR wording
* added PR template
* improved formatting in issue template
* removed checkbox for concept due to new GH discussions process
* improved wording
* improved PR todo list
* amended PR checklist; minor rewording
* removed duplicate wording
* add securtiy check section to contribution guide
* feat: include user in onLiveQueryEvent
* Update ParseLiveQuery.spec.js
* increase coverage
* add space
* Update ParseLiveQuery.spec.js
* remove user from runLiveQueryEventHandlers
* Trying to setup GitHub Actions
* Try to fix the workflow steps
* Fix NODE_VERSION
* Fix services
* Fix services 2
* Fix redis service, remove docker service
* Missing npm install
* Fix Use Node.js step name
* Remove greenkeeper
* I believe we do not need this command
* Try to include postgres
* Fix postgres script
* Remove before install script
* Fix postgres before script
* Try to fix connection to postgres
* Fix postgress port
* Postgres host
* Still trying to connect on postgres
* Still trying to connect on postgres - localhost
* Split postgres in a separate job
* Add postgres healthcheck
* Set postgres just like github example
* Fix postgres scripts with new credentials
* Still trying to fix postgres connection
* Now it looks only the username is wrong
* Passing postgres password in the right way
* try to install postgis
* New attempt to install postgis
* Fix postgis image name
* Try to output tests
* We need to start mongo
* Increase tests timeout
* Fix flaky test
* Add GitHub Actions badge
* Badge as html
* Fix badge link
* Remove Travis
* try to fix coverage
* Fix flaky test
* Improve ci workflow
* Change the mongo default test version
* Fix the job name in the if clause
* Ubuntu18.0.4
* Downgrade to 4.0.21
* Fix cache keys:
* Trying with mongo 4.0.4
* Rever os and mongo versions
* remove latest node
* strip password after authentication to prevent cleartext password storage
* fixed forgotten testcase forcing ;-/
* added test to check if password is not stored in user record
Co-authored-by: Fabian Strachanski <fabian@fastr.de>
* Add LDAPS-support to LDAP-Authcontroller
* Add Testcase that failed with valid certificate but wrong credendtials to LDAP-Authcontroller
* change scope of 'error' and remove 'case undefined', because it's not needed anymore
* Update PostgresStorageAdapter.js
Improve `createClass` transaction:
* `await` makes it a more consistent sequence of queries
* `batch` is not needed there
* No need for an extra `.then` section
* Update PostgresStorageAdapter.js
Remove batch-dependent error code check, as it should happen automatically without batch result.
* Update PostgresStorageAdapter.js
Removing unused variable.
* add fileKey encryption to GridFSBucketStorageAdapter
* remove fileAdapter options from test spec
* ensure promise doesn't fall through in getFileData
* switch secretKey to fileKey
* add fileKey rotation for GridFSBucketAdapter
* improve catching decryption errors in testcases
* add testcase for rotating key from oldKey to noKey leaving all files decrypted
* removed fileKey from legacy test links. From the looks of the tests and the fileKey was appended to links. This key is now an encryption key
* clean up code
* make more consistant with FSAdapter
* use encryptionKey instead of fileKey
* Update ParseFile.spec.js
revert
* Make hostnameMaxLen an environment variable.
In our Mongo cluster, we have 2 shards equalling 7 hosts that come in as a long comma-delimited list of host names. This hostNameMaxLen of 255 should not apply to a mongo connection string like that:
mongodb://<USER>:<PASSWORD>@MYCLUSTER-shard-00-00.luszb.azure.mongodb.net:27016,MYCLUSTER-shard-00-01.luszb.azure.mongodb.net:27016,MYCLUSTER-shard-00-02.luszb.azure.mongodb.net:27016,MYCLUSTER-shard-00-03.luszb.azure.mongodb.net:27016,MYCLUSTER-shard-02-00.luszb.azure.mongodb.net:27016,MYCLUSTER-shard-02-01.luszb.azure.mongodb.net:27016,MYCLUSTER-shard-02-02.luszb.azure.mongodb.net:27016/dev?ssl=true&authSource=admin
We was using the SRV mongo connection string type which is much shorter:
mongodb+srv://<USER>:<PASSWORD>@MYCLUSTER-luszb.azure.mongodb.net/dev
But we were finding it to be unreliable with Azure's DNS. We rarely change our cluster configuration, so having the long connection string would be more reliable
If these changes should be approached in some other manner, I'd be happy to do that.
* Update mongodbUrl.js
Co-authored-by: Diamond Lewis <findlewis@gmail.com>
* prepend className to unique index to allow multiple unique indexes for different classes
* add testcase
* switched test so it can be tested on older versions of parse-server and show failure
* get rid of console log messages on restart by checking if the index exists before creating it
* add IF NOT EXISTS and IF EXISTS to ALTER TABLE
* revert some of code
* ensureIndex use IF NOT EXISTS
* ALTER TABLE CONSTRAINT can't use IF, ADD/DROP COLUMN can
* retesting
* update
* switchted to CREATE UNIQUE INDEX instrad of ALTER TABLE... ALTER TABLE doesn't seem to be needed
* Retrieve user concerned by email verification and ser objectId into query
* Linter ok
* Testing live query fired when email validation done
* Setting objectId into query if user exists
* Setting objectId into query if user exists
* Optimize query, fixes some null returns, fix stitched GraphQLUpload
* Fix authData key selection
* Prefer Iso string since other GraphQL solutions use this format
* fix tests
Co-authored-by: Antonio Davi Macedo Coelho de Castro <adavimacedo@gmail.com>
* updated defaultURL to allow new insta API access
* updated defaultURL to allow new insta API access
* updates tests for new instagram API url
Co-authored-by: Tim Talbot <tim@dyingmethod.com>
* add test cases for geoNear aggregation
Test cases do not have the `query` parameter set in $geoNear aggregation stage. this is to test for a reported potential issue when the parameter is not set.
* fixed potential issue when setting the geoNear.query parameter to undefined
see dicussion in https://github.com/parse-community/parse-server/pull/6540
* fixed duplicate index name in test
* Updated TOKEN_ISSUER to 'accounts.google.com'
Hi, I was getting this issue from today morning parse-server/Adapters/Auth/google.js was expecting the TOKEN_ISSUER to be prefixed with https:// but on debugging the original value was not having the prefix, removing https:// from TOKEN_ISSUER solved this bug. This issue is introduced in 4.3.0 as in 4.2.0 it is working fine currently I have downgraded the version to 4.2.0 for it to work properly and suggesting the changes please merge this PR.
* Update google.js
* Update AuthenticationAdapters.spec.js
* Update google.js
* Update google.js
* Optimize CLP pointer query
* remove console log
* Update changelog
* Fix flow type checker issues
* Remove unused properties
* Fix typo, add one more test case for coverage
* Add support for CLP entry of type Object
Co-authored-by: Musa Yassin-Fort <musa.yassin@bureapr.com>
Co-authored-by: Diamond Lewis <findlewis@gmail.com>
* fix(direct-access): save context not present if direct access enabled
[Open discussion](https://github.com/parse-community/parse-server/issues/6459) for feature with other issues
* only send context when present
* use object spread
* revert and add test
* rename test
Co-authored-by: dplewis <findlewis@gmail.com>
* Before Connect + Before Subscribe #1
* Cleanup and Documentation
* Add E2E tests
* Bump parse to 2.15.0
Co-authored-by: Diamond Lewis <findlewis@gmail.com>
* add fileKey encryption to GridFSBucketStorageAdapter
* remove fileAdapter options from test spec
* ensure promise doesn't fall through in getFileData
* switch secretKey to fileKey
* chore(package): update @babel/cli to version 7.10.0
* chore(package): update @babel/core to version 7.10.0
* chore(package): update @babel/plugin-proposal-object-rest-spread to version 7.10.0
* chore(package): update @babel/preset-env to version 7.10.0
* chore(package): update lockfile package-lock.json
Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
* chore(package): update apollo-cache-inmemory to version 1.6.6
* chore(package): update apollo-client to version 2.6.9
* chore(package): update apollo-utilities to version 1.3.4
* chore(package): update lockfile package-lock.json
Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
* Support Metadata in GridFSAdapter
* Useful for testing in the JS SDK
* Adds new endpoint to be used with `Parse.File.getData`
* Allows file adapters to return tags as well as future data.
* fix tests
* Make getMetadata optional
* Revert "fix tests"
This reverts commit 7706da13c6.
* improve coverage
* chore(package): update @babel/core to version 7.9.6
* chore(package): update @babel/plugin-proposal-object-rest-spread to version 7.9.6
* chore(package): update @babel/preset-env to version 7.9.6
* chore(package): update lockfile package-lock.json
Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
* use pg-promise native pg-connection-string to parse uri instead of ParseConfigParser.js. The allows for a more felxible uri for ssl and other params
* added ssl config params and others to PostgresConfigParser
* forgot to add back the original client file
* need to read in file at path for pfx, ca, key, and key
* convert file buffer to string to be consistant with node-postgres examples
* use pg-promise native pg-connection-string to parse uri instead of ParseConfigParser.js. The allows for a more felxible uri for ssl and other params
* Revert "use pg-promise native pg-connection-string to parse uri instead of ParseConfigParser.js. The allows for a more felxible uri for ssl and other params"
This reverts commit a5926d3ff7.
* Updating travis postgres and removing unnecessary start of mongo-runner. Ensuring before_script and before_install matches the rest of travis
* Fixing objectId for Pointer in Postgres
* add test case for longer objectId pointer. Note that this test fails on Postgres before the addition of previous commit
* removed comment that wasn't needed
* Add test case for order option when extending the schema
* Remove fit
* upgrade to graphql-tools v5
revert #6515
Co-authored-by: Antonio Davi Macedo Coelho de Castro <adavimacedo@gmail.com>
* chore(package): update apollo-link-http to version 1.5.17
* chore(package): update apollo-link-ws to version 1.0.20
* chore(package): update apollo-link to version 1.2.14
* chore(package): update lockfile package-lock.json
Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
* Apply linter changes on files I'm about to update
My actual changes were quite difficult to find when buried in this sea
of style changes, which were getting automatically applied during a
pre-commit hook. Here I just run the hooks against the files I'm going
to be touching in the following commit, so that a reviewer can ignore
these automatically generated diffs and just view the meaningful commit.
* perf: Allow covering relation queries with minimal index
When finding objects through a relation, we're sending Mongo queries
that look like this:
```
db.getCollection('_Join:foo:bar').find({ relatedId: { $in: [...] } });
```
From the result of that query, we're only reading the `owningId` field,
so we can start by adding it as a projection:
```
db.getCollection('_Join:foo:bar')
.find({ relatedId: { $in: [...] } })
.project({ owningId: 1 });
```
This seems like the perfect example of a query that could be satisfied
with an index scan: we are querying on one field, and only need one
field from the matching document.
For example, this can allow users to speed up the fetching of user roles
in authentication, because they query a `roles` relation on the `_Role`
collection. To add a covering index on that, you could now add an index
like the following:
```
db.getCollection('_Join:roles:_Role').createIndex(
{ relatedId: 1, owningId: 1 },
{ background: true }
);
```
One caveat there is that the index I propose above doesn't include the
`_id` column. For the query in question, we don't actually care about
the ID of the row in the join table, just the `owningId` field, so we
can avoid some overhead of putting the `_id` column into the index if we
can also drop it from the projection. This requires adding a small
special case to the MongoStorageAdapter, because the `_id` field is
special: you have to opt-out of using it by projecting `{ _id: 0 }`.
* Prep release 4.2
* fix links, consistent formatting
* remove unnecessary credit
* add one more commit
* Fix link, remove double spaces
* add a few more commits
run npm audit fix
* little fixes
Co-authored-by: Tom Fox <13188249+TomWFox@users.noreply.github.com>
* Update .travis.yml
testing error to see what happens...
* Update .travis.yml
Attempting to resolve postgres in CL by installing postgis via sudo instead of through apt/packages
* Update .travis.yml
* Update .travis.yml
* Update .travis.yml
Removed extra lines of postgres that were under "services" and "addons". I believe the "postgresql" line under "services" was installing the default of 9.6 and "addons" was installing postgres 11. My guess is the fail was occurring due to 9.6 being called sometimes and it never had postgis installed. If this is true, the solution is to only install one version of postgres, which is version 11 with postgis 2.5.
* Adding test case for caseInsensitive
Adding test case for verifying indexing for caseInsensitive
* Implementing ensureIndex
* Updated PostgresStorageAdapter calls to ST_DistanceSphere. Note this has a minimum requirement of postgis 2.2. Documented the change in the readme. This is address #6441
* updated postgres sections of contributions with newer postgres info. Also switched postgis image it points to as the other one hasn't been updated in over a year.
* more info about postgres
* added necessary password for postgres docker
* updated wording in contributions
* removed reference to MacJr environment var when starting postgres in contributions. The official image automatically creates a user named 'postgres', but it does require a password, which the command sets to 'postgres'
* added more time to docker sleep/wait to enter postgis commands. This will always take a few seconds because the db is installing from scratch everytime. If postgres/postgis images aren't already downloaded locally, it will take even longer. Worst case, if the command times out on first run. Stop and remove the parse-postgres container and run the command again, 20 seconds should be enough wait time then
* latest changes
* initial fix, need to test
* fixed lint
* Adding test case for caseInsensitive
Adding test case for verifying indexing for caseInsensitive
* Implementing ensureIndex
* Updated PostgresStorageAdapter calls to ST_DistanceSphere. Note this has a minimum requirement of postgis 2.2. Documented the change in the readme. This is address #6441
* updated postgres sections of contributions with newer postgres info. Also switched postgis image it points to as the other one hasn't been updated in over a year.
* more info about postgres
* added necessary password for postgres docker
* updated wording in contributions
* removed reference to MacJr environment var when starting postgres in contributions. The official image automatically creates a user named 'postgres', but it does require a password, which the command sets to 'postgres'
* added more time to docker sleep/wait to enter postgis commands. This will always take a few seconds because the db is installing from scratch everytime. If postgres/postgis images aren't already downloaded locally, it will take even longer. Worst case, if the command times out on first run. Stop and remove the parse-postgres container and run the command again, 20 seconds should be enough wait time then
* latest changes
* initial fix, need to test
* fixed lint
* Adds caseInsensitive constraints to database, but doesn't pass regular tests. I believe this is because ensureIndex in the Postgres adapter is returning wrong. Also, some issues with the caseInsensitive test case
* this version addes the indexes, but something still wrong with the ensureIndex method in adapter
* removed code from suggestions
* fixed lint
* fixed PostgresAdapter test case
* small bug in test case
* reverted back to main branch package.json and lock file
* fixed docker command in Contribute file
* added ability to explain the find method
* triggering another build
* added ability to choose to 'analyze' a query which actually executes (this can be bad when looking at a query plan for Insert, Delete, etc.) the query or to just setup the query plan (default, previous versions defaulted to 'analyze'). Alse added some comparsons on sequential vs index searches for postgres
* made sure to check that search actually returns 1 result. Removed prep time comparison between searches as this seemed to be variable
* added test cases using find and case insensitivity on fields other than username and password. Also added explain to aggregate method
* fixing issue where query in aggregate replaced the map method incorrectly
* reverted back to mapping for aggregate method to make sure it's the issue
* switched back to caseInsensitive check for email and username as it was causing issues
* fixed aggregate method using explain
* made query plain results more flexible/reusable. Got rid of droptables as 'beforeEach' already handles this
* updated CONTRIBUTING doc to use netrecon as default username for postgres (similar to old style). Note that the official postgres docker image for postgres requires POSTGRES_PASSWORD to be set in order to use the image
* left postgis at 2.5 in the contributing document as this is the last version to be backwards compatibile with older versions of parse server
* updating docker command for postgres
Co-authored-by: Arthur Cinader <700572+acinader@users.noreply.github.com>
* Attempting to fix Postgres issue
* Attempting to fix Postgres issue
trying to stop loop
* Attempting to fix Postgres
isolating postgres calls
* Attempting to fix Postgres issue
Separating jobs
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
Separating builds again
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
Just added back version 10, just in case it gets called
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Update .travis.yml
* Attempting to fix postgres
Removed postgres installs from unneeded test cases. Added the ability to test Postgres 10 and 11
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
Added test for postgres 12 that's allowed to fail
* Attempting to fix postgres
* Attempting to fix postgres
Second round to see if it fails eventually
* Attempting to fix postgres
Round 3
* Attempting to fix postgres
Allowing all postgres to fail since it seems to occur randomly
* Temporary fix: separated mongo and postgres in travis
Now the mongo and postgres scripts are independent of each other to prevent the `ERROR: could not access file "$libdir/postgis-2.4": No such file or directory` of showing up in the rest of the builds.
In addition, a test for postgres-12 has been added for future compatibility. Both the postgres-11 and postgres-12 have been added to `allow_failures` because the aforementioned error still creeps up. Important note is that the error has nothing to do with compatibility with postgres, but rather seems to be an error of how postgres (or really postgis) is being referenced in the respective travis distribution. Lastly, this error, if truly random should appear less than before as the postgres scripts aren't being run for every build as it previously was running.
* Allowing all postgres to fail
* Allowing multiple names to fail
* Removing preinstalled versions of postgres from list
Seeing if this gets rid of the random error
* Use postgres made for dist
* Second round
* Round 3
* Round 4
* Round 5
* Fixed issue with random postgres fail
Removing the native postgres builds at the right time seems to have fixed the random error from before.
The postgres tests are now not allowed to fail.
* Added back postgres 11 and 12 to allow_failures
The actual problem is fixed, but it seems there are some instability with some of the test cases for postgres that need to be addressed at another time.
The issues that pop up are:
- Postgres-11
```Failures:
1) Cloud Code cloud jobs should set the message / success on the job
Message:
Expected undefined to equal 'hello'.
Stack:
Error: Expected undefined to equal 'hello'.
at <Jasmine>
at req.message.then.then.jobStatus (/home/travis/build/parse-community/parse-server/spec/CloudCode.spec.js:1571:46)
at process._tickCallback (internal/process/next_tick.js:68:7)
```
- Postgres-12
```
Failures:
1) Cloud Code cloud jobs should set the message / success on the job
Message:
Expected undefined to equal 'hello'.
Stack:
Error: Expected undefined to equal 'hello'.
at <Jasmine>
at req.message.then.then.jobStatus (/home/travis/build/parse-community/parse-server/spec/CloudCode.spec.js:1571:46)
at process._tickCallback (internal/process/next_tick.js:68:7)
Message:
Expected 'running' to equal 'succeeded'.
Stack:
Error: Expected 'running' to equal 'succeeded'.
at <Jasmine>
at promise.then.then.jobStatus (/home/travis/build/parse-community/parse-server/spec/CloudCode.spec.js:1580:45)
at process._tickCallback (internal/process/next_tick.js:68:7)
```
* added travis scripts for postgres
* Setting up before_install and before_script
This should shrink the footprint of the file and and reduce the redundancy of calls for postgres.
Added support for testing of Postgres 9 and 10 in the scripts, not adding the tests though
* make scripts executable
* Update .travis.yml
* add sourcing in script
* trying to fix source
* fixing env var in script
* fixed ; near then
* Cleaning up travis file
removed old lines
* Finishing clean up
* Fixing allow_failures since "name" was removed
* Update .travis.yml
* Removed Postgres 11 from allow_failures
* I think using travis default postgres port of 5433 will allow us to not have to remove anything from the image
* Switching travis to postgres port 5433
* modifying script for test
* modifying script for test
* modifying script for test
* reverting back to working way with removing postgres from image
* Reverted back to removing postgres from image
* removing postgres 12
* removed postgres-12 from allow_failures
* updated postgres method from deprecated. Also updating postgis to 3.0
* updated postgis to 3.0
* Update .travis.yml
* fix Postgres test issues that causes some tests to fail locally when using PARSE_SERVER_TEST_DATABASE_URI
* removed dependence on creating adapter locally in testcase and use config instead.
* fixed one more potential issue with postgres adapter
* modified travis and script to leverage PARSE_SERVER_TEST_DATABASE_URI
* changes to before install to reduce time
* add updated port to script for psql connection
* fixed arg for psql
* added back conf file as it probably contains the default permissions
* seeing if stopping/starting postgres back-to-back was the issue
* checking fix
* revert to working version of install script
* leave default port
* removing uninstall of postgres from script
* looks like postgres won't start until the others are removed
* forgoing using posgres service and starting directly, hoping it allows to skip remove
* removed sudo for starting postgres
* adding back sude, but using default user for postgres
* fix
* don't start service
* init db cluster before starting
* remove folder befor init
* remove folder befor init
* still have to stop service
* switch ports after new configs are made
* switch ports after new configs are made
* went back to removing to get it to start properly
* seeing if you can use postgres installaition out of the box
* seeing if you can use postgres installaition out of the box
* copy hba file, then stop,start
* testing using port as argument
* working version
* round 2
* updated documentation to reflect changes
* use restart instead of stop/start for postgres
* removed extra lines to ensure consistency with future builds
* reload instead of restart postgres
* restart postgres since we can't currently connect
* Switch to testonly for postgres
* run testonly
* Declare as mongo test since it's handed coded to a mongo uri
* added hint to aggregate
* added support for hint in query
* added else clause to aggregate
* fixed tests
* updated tests
* Add tests and clean up
* added beforeSaveFile and afterSaveFile triggers
* Add support for explain
* added some validation
* added support for metadata and tags
* tests?
* trying tests
* added tests
* fixed failing tests
* added some docs for fileObject
* updated hooks to use Parse.File
* added test for already saved file being returned in hook
* added beforeDeleteFile and afterDeleteFile hooks
* removed contentLength because it's already in the header
* added fileSize param to FileTriggerRequest
* added support for client side metadata and tags
* removed fit test
* removed unused import
* added loging to file triggers
* updated error message
* updated error message
* fixed tests
* fixed typos
* Update package.json
* fixed failing test
* fixed error message
* fixed failing tests (hopefully)
* TESTS!!!
* Update FilesAdapter.js
fixed comment
* added test for changing file name
* updated comments
Co-authored-by: Diamond Lewis <findlewis@gmail.com>
* added failing test case
* add date conversion for geoNear query
- geoNear stages were not parsed for date fields, but mongodb nodejs adapter requires date object
* reverted unnecessary code auto-formatting
* limited parsing to query property of geoNear stage
- the geoNear object contains parameter keys which could be identical to field names in the collection, which should not be parsed and changed, therefore restricting parsing only to query parameter key
* reverted unnecessary code auto-formatting
* added index type parameter to ensureIndex
- required to create geo index for geoNear test
* added geo index creation to test case
* fixed dates in test case
- test case likey failed due to date rounding
* added error output to console
- temporary, to find out why test fails on mongodb 3.6.9
* create seperate class to avoid multiple geo indices on TestObject class
- mongodb <4.0 does not allow nultiple geo indices on a class when using geoNear
- see https://docs.mongodb.com/v3.6/reference/operator/aggregation/geoNear/#behavior
* fixed incorrect result validation
- results were not ordered properly, so test validation failed sometimes
* removed error output to console
This reverts commit da81c515cb.
* Attempting to fix Postgres issue
* Attempting to fix Postgres issue
trying to stop loop
* Attempting to fix Postgres
isolating postgres calls
* Attempting to fix Postgres issue
Separating jobs
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
Separating builds again
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
Just added back version 10, just in case it gets called
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Update .travis.yml
* Attempting to fix postgres
Removed postgres installs from unneeded test cases. Added the ability to test Postgres 10 and 11
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
Added test for postgres 12 that's allowed to fail
* Attempting to fix postgres
* Attempting to fix postgres
Second round to see if it fails eventually
* Attempting to fix postgres
Round 3
* Attempting to fix postgres
Allowing all postgres to fail since it seems to occur randomly
* Temporary fix: separated mongo and postgres in travis
Now the mongo and postgres scripts are independent of each other to prevent the `ERROR: could not access file "$libdir/postgis-2.4": No such file or directory` of showing up in the rest of the builds.
In addition, a test for postgres-12 has been added for future compatibility. Both the postgres-11 and postgres-12 have been added to `allow_failures` because the aforementioned error still creeps up. Important note is that the error has nothing to do with compatibility with postgres, but rather seems to be an error of how postgres (or really postgis) is being referenced in the respective travis distribution. Lastly, this error, if truly random should appear less than before as the postgres scripts aren't being run for every build as it previously was running.
* Allowing all postgres to fail
* Allowing multiple names to fail
* Removing preinstalled versions of postgres from list
Seeing if this gets rid of the random error
* Use postgres made for dist
* Second round
* Round 3
* Round 4
* Round 5
* Fixed issue with random postgres fail
Removing the native postgres builds at the right time seems to have fixed the random error from before.
The postgres tests are now not allowed to fail.
* Added back postgres 11 and 12 to allow_failures
The actual problem is fixed, but it seems there are some instability with some of the test cases for postgres that need to be addressed at another time.
The issues that pop up are:
- Postgres-11
```Failures:
1) Cloud Code cloud jobs should set the message / success on the job
Message:
Expected undefined to equal 'hello'.
Stack:
Error: Expected undefined to equal 'hello'.
at <Jasmine>
at req.message.then.then.jobStatus (/home/travis/build/parse-community/parse-server/spec/CloudCode.spec.js:1571:46)
at process._tickCallback (internal/process/next_tick.js:68:7)
```
- Postgres-12
```
Failures:
1) Cloud Code cloud jobs should set the message / success on the job
Message:
Expected undefined to equal 'hello'.
Stack:
Error: Expected undefined to equal 'hello'.
at <Jasmine>
at req.message.then.then.jobStatus (/home/travis/build/parse-community/parse-server/spec/CloudCode.spec.js:1571:46)
at process._tickCallback (internal/process/next_tick.js:68:7)
Message:
Expected 'running' to equal 'succeeded'.
Stack:
Error: Expected 'running' to equal 'succeeded'.
at <Jasmine>
at promise.then.then.jobStatus (/home/travis/build/parse-community/parse-server/spec/CloudCode.spec.js:1580:45)
at process._tickCallback (internal/process/next_tick.js:68:7)
```
* added travis scripts for postgres
* Setting up before_install and before_script
This should shrink the footprint of the file and and reduce the redundancy of calls for postgres.
Added support for testing of Postgres 9 and 10 in the scripts, not adding the tests though
* make scripts executable
* Update .travis.yml
* add sourcing in script
* trying to fix source
* fixing env var in script
* fixed ; near then
* Cleaning up travis file
removed old lines
* Finishing clean up
* Fixing allow_failures since "name" was removed
* Update .travis.yml
* Removed Postgres 11 from allow_failures
* I think using travis default postgres port of 5433 will allow us to not have to remove anything from the image
* Switching travis to postgres port 5433
* modifying script for test
* modifying script for test
* modifying script for test
* reverting back to working way with removing postgres from image
* Reverted back to removing postgres from image
* removing postgres 12
* removed postgres-12 from allow_failures
* updated postgres method from deprecated. Also updating postgis to 3.0
* updated postgis to 3.0
* Update .travis.yml
* Update instagram.js
Instagram API was updated.
* Update instagram.js
Instagram API was updated and is not allowing anymore to setup new projects to use the old style but it is still working for the ones that have it already setup.
New docs are listed here: https://developers.facebook.com/docs/instagram-basic-display-api/
I've added support for both old and new API
To use new API just add new field "api_type" = "new_api" in client side.
For old API just no changes needed.
* support api url
Co-authored-by: Diamond Lewis <findlewis@gmail.com>
* updated 2 files for allowing multiple client ids
* updated tests that fail due to user inputting data in code, added todo comment to them stating what we need to do to fix them
* chore(package): update @babel/core to version 7.9.0
* chore(package): update @babel/plugin-proposal-object-rest-spread to version 7.9.0
* chore(package): update @babel/plugin-transform-flow-strip-types to version 7.9.0
* chore(package): update @babel/preset-env to version 7.9.0
* chore(package): update lockfile package-lock.json
Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
* Attempting to fix Postgres issue
* Attempting to fix Postgres issue
trying to stop loop
* Attempting to fix Postgres
isolating postgres calls
* Attempting to fix Postgres issue
Separating jobs
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
Separating builds again
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
Just added back version 10, just in case it gets called
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Update .travis.yml
* Attempting to fix postgres
Removed postgres installs from unneeded test cases. Added the ability to test Postgres 10 and 11
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
* Attempting to fix postgres
Added test for postgres 12 that's allowed to fail
* Attempting to fix postgres
* Attempting to fix postgres
Second round to see if it fails eventually
* Attempting to fix postgres
Round 3
* Attempting to fix postgres
Allowing all postgres to fail since it seems to occur randomly
* Temporary fix: separated mongo and postgres in travis
Now the mongo and postgres scripts are independent of each other to prevent the `ERROR: could not access file "$libdir/postgis-2.4": No such file or directory` of showing up in the rest of the builds.
In addition, a test for postgres-12 has been added for future compatibility. Both the postgres-11 and postgres-12 have been added to `allow_failures` because the aforementioned error still creeps up. Important note is that the error has nothing to do with compatibility with postgres, but rather seems to be an error of how postgres (or really postgis) is being referenced in the respective travis distribution. Lastly, this error, if truly random should appear less than before as the postgres scripts aren't being run for every build as it previously was running.
* Allowing all postgres to fail
* Allowing multiple names to fail
* Removing preinstalled versions of postgres from list
Seeing if this gets rid of the random error
* Use postgres made for dist
* Second round
* Round 3
* Round 4
* Round 5
* Fixed issue with random postgres fail
Removing the native postgres builds at the right time seems to have fixed the random error from before.
The postgres tests are now not allowed to fail.
* Added back postgres 11 and 12 to allow_failures
The actual problem is fixed, but it seems there are some instability with some of the test cases for postgres that need to be addressed at another time.
The issues that pop up are:
- Postgres-11
```Failures:
1) Cloud Code cloud jobs should set the message / success on the job
Message:
Expected undefined to equal 'hello'.
Stack:
Error: Expected undefined to equal 'hello'.
at <Jasmine>
at req.message.then.then.jobStatus (/home/travis/build/parse-community/parse-server/spec/CloudCode.spec.js:1571:46)
at process._tickCallback (internal/process/next_tick.js:68:7)
```
- Postgres-12
```
Failures:
1) Cloud Code cloud jobs should set the message / success on the job
Message:
Expected undefined to equal 'hello'.
Stack:
Error: Expected undefined to equal 'hello'.
at <Jasmine>
at req.message.then.then.jobStatus (/home/travis/build/parse-community/parse-server/spec/CloudCode.spec.js:1571:46)
at process._tickCallback (internal/process/next_tick.js:68:7)
Message:
Expected 'running' to equal 'succeeded'.
Stack:
Error: Expected 'running' to equal 'succeeded'.
at <Jasmine>
at promise.then.then.jobStatus (/home/travis/build/parse-community/parse-server/spec/CloudCode.spec.js:1580:45)
at process._tickCallback (internal/process/next_tick.js:68:7)
```
* added travis scripts for postgres
* Setting up before_install and before_script
This should shrink the footprint of the file and and reduce the redundancy of calls for postgres.
Added support for testing of Postgres 9 and 10 in the scripts, not adding the tests though
* make scripts executable
* Update .travis.yml
* add sourcing in script
* trying to fix source
* fixing env var in script
* fixed ; near then
* Cleaning up travis file
removed old lines
* Finishing clean up
* Fixing allow_failures since "name" was removed
* Update .travis.yml
* Removed Postgres 11 from allow_failures
* I think using travis default postgres port of 5433 will allow us to not have to remove anything from the image
* Switching travis to postgres port 5433
* modifying script for test
* modifying script for test
* modifying script for test
* reverting back to working way with removing postgres from image
* Reverted back to removing postgres from image
* removing postgres 12
* removed postgres-12 from allow_failures
* use token and algo from jwt header
* change node-rsa out for jwks-rsa, reflect change in tests and add one test for coverage
* remove superfluous cache, allow jwks cache parameters to be passed to validateAuthData
* remove package lock
* regenerate package lock
* try fixing package-lock with copy from master
* manual changes for merge conflict
* whitespace
* pass options as object
* fix inconsistent variable name
Update .travis.yml (#6490)
* Update .travis.yml
testing error to see what happens...
* Update .travis.yml
Attempting to resolve postgres in CL by installing postgis via sudo instead of through apt/packages
* Update .travis.yml
* Update .travis.yml
* Update .travis.yml
Removed extra lines of postgres that were under "services" and "addons". I believe the "postgresql" line under "services" was installing the default of 9.6 and "addons" was installing postgres 11. My guess is the fail was occurring due to 9.6 being called sometimes and it never had postgis installed. If this is true, the solution is to only install one version of postgres, which is version 11 with postgis 2.5.
* Group aggregation supports multiple columns for postgres
* Group aggregation supports multiple columns for postgres
* Group aggregation supports multiple columns for postgres
* Group aggregation supports multiple columns for postgres
* bump version
* add the special note
* remove new version & add note about indexes to 4.0.2 & 4.0.0
* Update package-lock.json
* Update package.json
* add line break
* remove double space
Co-authored-by: Tom Fox <13188249+TomWFox@users.noreply.github.com>
* chore(package): update @babel/core to version 7.8.7
* chore(package): update @babel/preset-env to version 7.8.7
* chore(package): update lockfile package-lock.json
* Fix session token issue
* verify email problem
* Fix password reset problem
* Change test file name
* Split tests
* Refetch user
* Replaces lets to consts
* Refactor unit test
What you have is just finee, but wanted
to show you what I meant with my comment
Use jasmine's this to set stuff in beforeEach's
Not that all functions need to be `function ()` instead of
`() =>` so `this` is preserved.
see: https://jasmine.github.io/tutorials/your_first_suite#section-The_%3Ccode%3Ethis%3C/code%3E_keyword
Co-authored-by: Antonio Davi Macedo Coelho de Castro <adavimacedo@gmail.com>
**Please use this template. If you don't use this template, your issue may be closed without comment.**
We use GitHub Issues for bugs.
If you have a non-bug question, ask on [Parse Community's Discourse forum](https://community.parseplatform.org/c/parse-server)
If you have a vulnerability disclosure, please follow our policy available here https://github.com/parse-community/parse-server/blob/master/SECURITY.md
You may also search through existing issues before opening a new one: https://github.com/parse-community/parse-server/issues?utf8=%E2%9C%93&q=is%3Aissue
-->
### Issue Description
<!-- Describe your issue in as much detail as possible. -->
### Steps to reproduce
<!-- Please include a detailed list of steps that reproduce the issue. Include curl commands when applicable. -->
#### Expected Results
<!-- What you expected to happen. -->
#### Actual Outcome
<!-- What is happening instead. -->
### Environment Setup
- **Server**
- parse-server version (Be specific! Don't say 'latest'.) : [FILL THIS OUT]
- Operating System: [FILL THIS OUT]
- Hardware: [FILL THIS OUT]
- Localhost or remote server? (AWS, Heroku, Azure, Digital Ocean, etc): [FILL THIS OUT]
- **Database**
- MongoDB version: [FILL THIS OUT]
- Storage engine: [FILL THIS OUT]
- Hardware: [FILL THIS OUT]
- Localhost or remote server? (AWS, mLab, ObjectRocket, Digital Ocean, etc): [FILL THIS OUT]
### Logs/Trace
Include all relevant logs. You can turn on additional logging by configuring VERBOSE=1 in your environment.
about:A feature of Parse Server is not working as expected.
title:''
labels:''
assignees:''
---
### New Issue Checklist
<!--
Check every following box [x] before submitting your issue.
Click the "Preview" tab for better readability.
Thanks for contributing to Parse Platform!
-->
- [ ] I am not disclosing a [vulnerability](https://github.com/parse-community/parse-server/blob/master/SECURITY.md).
- [ ] I am not just asking a [question](https://github.com/parse-community/.github/blob/master/SUPPORT.md).
- [ ] I have searched through [existing issues](https://github.com/parse-community/parse-server/issues?q=is%3Aissue).
- [ ] I can reproduce the issue with the [latest version of Parse Server](https://github.com/parse-community/parse-server/releases). <!-- We don't investigate issues for outdated releases. -->
### Issue Description
<!-- What is the specific issue with Parse Server? -->
### Steps to reproduce
<!-- How can someone else reproduce the issue? -->
### Actual Outcome
<!-- What outcome, for example query result, did you get? -->
### Expected Outcome
<!-- What outcome, for example query result, did you expect? -->
### Environment
<!-- Be specific with versions, don't use "latest" or semver ranges like "~x.y.z" or "^x.y.z". -->
Server
- Parse Server version: `FILL_THIS_OUT`
- Operating system: `FILL_THIS_OUT`
- Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): `FILL_THIS_OUT`
Database
- System (MongoDB or Postgres): `FILL_THIS_OUT`
- Database version: `FILL_THIS_OUT`
- Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): `FILL_THIS_OUT`
about:Report an issue while migrating to parse-server 3.0.0
---
<!---
** Use this template only if you have an issue migrating to parse-server 3.0.0 **
If you have a question, ask on [Parse Community's Discourse forum](https://community.parseplatform.org/c/parse-server)
If you have a vulnerability disclosure, please follow our policy available here https://github.com/parse-community/parse-server/blob/master/SECURITY.md
You may also search through existing issues before opening a new one: https://github.com/parse-community/parse-server/issues?utf8=%E2%9C%93&q=is%3Aissue
--- Please use this template. If you don't use this template, your issue may be closed without comment. ---
--->
# Before opening the issue please ensure that you have:
- [ ] [Read the migration guide](https://github.com/parse-community/parse-server/blob/master/3.0.0.md) to parse-server 3.0.0
- [ ] [Read the migration guide](https://github.com/parse-community/Parse-SDK-JS/blob/master/2.0.0.md) to Parse SDK JS 2.0.0
### Issue Description
<!--- Describe your issue in as much detail as possible. -->
### Steps to reproduce
<!--- Please include a detailed list of steps that reproduce the issue. Include curl commands when applicable. --->
### Expected Results
<!--- What you expected to happen. --->
### Actual Outcome
<!--- What is happening instead. --->
### Environment Setup
- **Server**
- parse-server version (Be specific! Don't say 'latest'.) : [FILL THIS OUT]
- Operating System: [FILL THIS OUT]
- Hardware: [FILL THIS OUT]
- Localhost or remote server? (AWS, Heroku, Azure, Digital Ocean, etc): [FILL THIS OUT]
- **Database**
- MongoDB version: [FILL THIS OUT]
- Storage engine: [FILL THIS OUT]
- Hardware: [FILL THIS OUT]
- Localhost or remote server? (AWS, mLab, ObjectRocket, Digital Ocean, etc): [FILL THIS OUT]
### Logs/Trace
<!--- Include all relevant logs. You can turn on additional logging by configuring VERBOSE=1 in your environment. --->
If you have a vulnerability disclosure, please follow our policy available here https://github.com/parse-community/parse-server/blob/master/SECURITY.md
You may also search through existing issues before opening a new one: https://github.com/parse-community/parse-server/issues?utf8=%E2%9C%93&q=is%3Aissue
--- Please use this template. If you don't use this template, your issue may be closed without comment. ---
--->
### Issue Description
<!--- Describe your issue in as much detail as possible. -->
### Push Configuration
Please provide a copy of your `push` configuration here, obfuscating any sensitive part.
### Environment Setup
- **Server**
- parse-server version (Be specific! Don't say 'latest'.) : [FILL THIS OUT]
- Operating System: [FILL THIS OUT]
- Hardware: [FILL THIS OUT]
- Localhost or remote server? (AWS, Heroku, Azure, Digital Ocean, etc): [FILL THIS OUT]
- **Database**
- MongoDB version: [FILL THIS OUT]
- Storage engine: [FILL THIS OUT]
- Hardware: [FILL THIS OUT]
- Localhost or remote server? (AWS, mLab, ObjectRocket, Digital Ocean, etc): [FILL THIS OUT]
### Logs/Trace
<!--- Include all relevant logs. You can turn on additional logging by configuring VERBOSE=1 in your environment. --->
**We use GitHub Issues for reporting bugs with parse-server.**
If you have a *question*, you should join the [Parse Community's Discourse forum](https://community.parseplatform.org/c/parse-server).
If you have a vulnerability disclosure, please follow our policy available here https://github.com/parse-community/parse-server/blob/master/SECURITY.md
You may also search through existing issues before opening a new one: https://github.com/parse-community/parse-server/issues?utf8=%E2%9C%93&q=is%3Aissue
--- Please use this template. If you don't use this template, your issue may be closed without comment. ---
--->
### Issue Description
<!--- Describe your issue in as much detail as possible. -->
### Steps to reproduce
<!--- Please include a detailed list of steps that reproduce the issue. Include curl commands when applicable. --->
### Expected Results
<!--- What you expected to happen. --->
### Actual Outcome
<!--- What is happening instead. --->
### Environment Setup
- **Server**
- parse-server version (Be specific! Don't say 'latest'.) : [FILL THIS OUT]
- Operating System: [FILL THIS OUT]
- Hardware: [FILL THIS OUT]
- Localhost or remote server? (AWS, Heroku, Azure, Digital Ocean, etc): [FILL THIS OUT]
- **Database**
- MongoDB version: [FILL THIS OUT]
- Storage engine: [FILL THIS OUT]
- Hardware: [FILL THIS OUT]
- Localhost or remote server? (AWS, mLab, ObjectRocket, Digital Ocean, etc): [FILL THIS OUT]
### Logs/Trace
<!--- Include all relevant logs. You can turn on additional logging by configuring VERBOSE=1 in your environment. --->
This pull request was created because a new release is due according to the release cycle of this repository.
Just resolve any conflicts and it's good to merge. Any version increment will be done by release automation.
*⚠️ Use `Merge commit` to merge this pull request. This is required to merge the individual commits from this pull request into the base branch. Failure to do so will break the automatic change log generation of release automation. Do not use "Squash and merge"!*
This pull request was created because a new release is due according to the release cycle of this repository.
Just resolve any conflicts and it's good to merge. Any version increment will be done by release automation.
*⚠️ Use `Merge commit` to merge this pull request. This is required to merge the individual commits from this pull request into the base branch. Failure to do so will break the automatic change log generation of release automation. Do not use "Squash and merge"!*
If you are not familiar with Pull Requests and want to know more about them, you can visit the [Creating a pull request](https://help.github.com/articles/creating-a-pull-request/) article. It contains detailed informations about the process.
## Contributing
## Setting up the project for debugging and contributing:
Before you start to code, please open a [new issue](https://github.com/parse-community/parse-server/issues/new/choose) to describe your idea, or search for and continue the discussion in an [existing issue](https://github.com/parse-community/parse-server/issues).
### Recommended setup:
> ⚠️ Please do not post a security vulnerability on GitHub or in the Parse Community Forum. Instead, follow the [Parse Community Security Policy](https://github.com/parse-community/parse-server/security/policy).
* [vscode](https://code.visualstudio.com), the popular IDE.
Please completely fill out any templates to provide essential information about your new feature or the bug you discovered.
Together we will plan out the best conceptual approach for your contribution, so that your and our time is invested in the best possible approach. The discussion often reveals how to leverage existing features of Parse Server to reach your goal with even less effort and in a more sustainable way.
When you are ready to code, you can find more information about opening a pull request in the [GitHub docs](https://help.github.com/articles/creating-a-pull-request/).
Whether this is your first contribution or you are already an experienced contributor, the Parse Community has your back – don't hesitate to ask for help!
## Why Contributing?
Buy cheap, buy twice. What? No, this is not the Economics 101 class, but the same is true for contributing.
There are two ways of writing a feature or fixing a bug. Sometimes the quick solution is to just write a Cloud Code function that does what you want. Contributing by making the change directly in Parse Server may take a bit longer, but it actually saves you much more time in the long run.
Consider the benefits you get:
- #### 🚀 Higher efficiency
Your code is examined for efficiency and interoperability with existing features by the community.
- #### 🛡 Stronger security
Your code is scrutinized for bugs and vulnerabilities and automated checks help to identify security issues that may arise in the future.
- #### 🧬 Continuous improvement
If your feature is used by others it is likely to be continuously improved and extended by the community.
- #### 💝 Giving back
You give back to the community that contributed to make the Parse Platform become what it is today and for future developers to come.
- #### 🧑🎓 Improving yourself
You learn to better understand the inner workings of Parse Server, which will help you to write more efficient and resilient code for your own application.
Most importantly, with every contribution you improve your skills so that future contributions take even less time and you get all the benefits above for free — easy choice, right?
## Environment Setup
### Recommended Tools
* [Visual Studio Code](https://code.visualstudio.com), the popular IDE.
* [Jasmine Test Explorer](https://marketplace.visualstudio.com/items?itemName=hbenl.vscode-jasmine-test-adapter), a very practical test exploration plugin which let you run, debug and see the test results inline.
### Setting up you local machine:
### Setting up your local machine
* [Fork](https://github.com/parse-community/parse-server) this project and clone the fork on your local machine:
@@ -27,13 +88,23 @@ $ npm run watch # run babel watching for local file changes
Once you have babel running in watch mode, you can start making changes to parse-server.
### Good to know:
### Good to Know
* The `lib/` folder is not commited, so never make changes in there.
* The `lib/` folder is not committed, so never make changes in there.
* Always make changes to files in the `src/` folder.
* 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:
### Troubleshooting
*Question*: I modify the code in the src folder but it doesn't seem to have any effect.<br/>
*Answer*: Check that `npm run watch` is running
@@ -42,7 +113,10 @@ Once you have babel running in watch mode, you can start making changes to parse
*Answer*: The easiest way is to install [Jasmine Test Explorer](https://marketplace.visualstudio.com/items?itemName=hbenl.vscode-test-explorer), it will let you run selectively tests and debug them.
*Question*: How do I deploy my forked version on my servers?<br/>
*Answer*: In your `package.json`, update the `parse-server` dependency to `https://github.com/MY_USERNAME/parse-server#MY_FEATURE`. Run `npm install`, commit the changes and deploy to your servers.
*Answer*: In your `package.json`, update the `parse-server` dependency to `https://github.com/[username]/parse-server#[branch/commit]`. Run `npm install`, commit the changes and deploy to your servers.
*Question*: How do I deploy my forked version using docker?<br/>
*Answer*: In your `package.json`, update the `parse-server` dependency to `https://github.com/[username]/parse-server#[branch/commit]`. Make sure the `npm install` step in your `Dockerfile` is running under non-privileged user for the ``npm run prepare`` step to work correctly. For official node images from hub.docker.com that non-privileged user is `node` with `/home/node` working directory.
### Please Do's
@@ -53,39 +127,305 @@ 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.
### Run your tests against Postgres (optional)
### 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 npm test`. You'll need to have postgres running on your machine and setup [appropriately](https://github.com/parse-community/parse-server/blob/master/.travis.yml#L37) 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:
- `describe_only_db('mongo')` // will create a `describe` that runs only on mongoDB
- `it_only_db('mongo')` // will make a test that only runs on mongo
- `it_exclude_dbs(['postgres'])` // will make a test that runs against all DB's but postgres
* Similarly, if your feature is intended to only work with PostgreSQL, you should disable MongoDB-specific tests with:
- `describe_only_db('postgres')` // will create a `describe` that runs only on postgres
- `it_only_db('postgres')` // will make a test that only runs on postgres
- `it_exclude_dbs(['mongo'])` // will make a test that runs against all DB's but mongo
#### Run a Parse Postgres with Docker
* If your feature is intended to work with MongoDB and PostgreSQL, you can include or exclude tests more granularly with:
To launch the compatible Postgres instance, copy and paste the following line into your shell:
- `it_only_mongodb_version('>=4.4')` // will test with any version of Postgres but only with version >=4.4 of MongoDB; accepts semver notation to specify a version range
- `it_exclude_mongodb_version('<4.4')` // will test with any version of Postgres and MongoDB, excluding version <4.4 of MongoDB; accepts semver notation to specify a version range
- `it_only_postgres_version('>=13')` // will test with any version of Mongo but only with version >=13 of Postgres; accepts semver notation to specify a version range
- `it_exclude_postgres_version('<13')` // will test with any version of Postgres and MongoDB, excluding version <13 of Postgres; accepts semver notation to specify a version range
[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:
You can also use the [postgis/postgis:13-3.2-alpine](https://hub.docker.com/r/postgis/postgis) image in a Dockerfile and copy this [script](https://github.com/parse-community/parse-server/blob/master/scripts/before_script_postgres.sh) to the image by adding the following lines:
If you want to make changes to [Parse Server Configuration][config] add the desired configuration to [src/Options/index.js][config-index] and run `npm run definitions`. This will output [src/Options/Definitions.js][config-def] and [src/Options/docs.js][config-docs].
```
#Install additional scripts. These are run in abc order during initial start
RUN chmod +x /docker-entrypoint-initdb.d/setup-dbs.sh
```
To view docs run `npm run docs` and check the `/out` directory.
Note that the script above will ONLY be executed during initialization of the container with no data in the database, see the official [Postgres image](https://hub.docker.com/_/postgres) for details. If you want to use the script to run again be sure there is no data in the /var/lib/postgresql/data of the container.
### Code of Conduct
## Breaking Changes
Breaking changes should be avoided whenever possible. For a breaking change to be accepted, the benefits of the change have to clearly outweigh the costs of developers having to adapt their deployments. If a breaking change is only cosmetic it will likely be rejected and preferred to become obsolete organically during the course of further development, unless it is required as part of a larger change. Breaking changes should follow the [Deprecation Policy](#deprecation-policy).
Please consider that Parse Server is just one component in a stack that requires attention. A breaking change requires resources and effort to adapt an environment. An unnecessarily high frequency of breaking changes can have detrimental side effects such as:
- "upgrade fatigue" where developers run old versions of Parse Server because they cannot always attend to every update that contains a breaking change
- less secure Parse Server deployments that run on old versions which is contrary to the security evangelism Parse Server intends to facilitate for developers
- less feedback and slower identification of bugs and an overall slow-down of Parse Server development because new versions with breaking changes also include new features we want to get feedback on
### Deprecation Policy
If you change or remove an existing feature that would lead to a breaking change, use the following deprecation pattern:
- Make the new feature or change optional, if necessary with a new Parse Server option parameter.
- Use a default value that falls back to existing behavior.
- Add a deprecation definition in `Deprecator/Deprecations.js` that will output a deprecation warning log message on Parse Server launch, for example:
> DeprecationWarning: The Parse Server option 'example' will be removed in a future release.
For deprecations that can only be determined ad-hoc during runtime, for example Parse Query syntax deprecations, use the `Deprecator.logRuntimeDeprecation()` method.
Deprecations become breaking changes after notifying developers through deprecation warnings for at least one entire previous major release. For example:
- `4.5.0` is the current version
- `4.6.0` adds a new optional feature and a deprecation warning for the existing feature
- `5.0.0` marks the beginning of logging the deprecation warning for one entire major release
- `6.0.0` makes the breaking change by removing the deprecation warning and making the new feature replace the existing feature
See the [Deprecation Plan](https://github.com/parse-community/parse-server/blob/master/DEPRECATIONS.md) for an overview of deprecations and planned breaking changes.
## Feature Considerations
### Security Checks
The Parse Server security checks feature warns developers about weak security settings in their Parse Server deployment.
A security check needs to be added for every new feature or enhancement that allows the developer to configure it in a way that weakens security mechanisms or exposes functionality which creates a weak spot for malicious attacks. If you are not sure whether your feature or enhancements requires a security check, feel free to ask.
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 [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, 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.
1. Change the Parse JS SDK dependency in [package.json](https://github.com/parse-community/parse-server/blob/master/package.json) of Parse Server to the newly released Parse JS SDK version, so that the new Parse Error is recognized by Parse Server.
1. When throwing the new Parse Error in code, do not hard-code the error code but instead reference the error code from the Parse Error. For example:
```javascript
throw new Parse.Error(Parse.Error.EXAMPLE_ERROR_CODE, 'Example error message.');
```
1. Choose a descriptive error message that provdes more details about the specific error scenario. Different error messages may be used for the same error code. For example:
```javascript
throw new Parse.Error(Parse.Error.FILE_SAVE_ERROR, 'The file could not be saved because it exceeded the maximum allowed file size.');
throw new Parse.Error(Parse.Error.FILE_SAVE_ERROR, 'The file could not be saved because the file format was incorrect.');
```
1. Add the new Parse Error to the [docs](https://github.com/parse-community/docs/blob/gh-pages/_includes/common/errors.md).
### Parse Server Configuration
Introducing new [Parse Server configuration][config] parameters requires the following steps:
1. Add parameters definitions in [/src/Options/index.js][config-index].
2. If the new parameter does not have one single value but is a parameter group (an object containing multiple sub-parameters):
- add the environment variable prefix for the parameter group to `nestedOptionEnvPrefix` in [/resources/buildConfigDefinition.js](https://github.com/parse-community/parse-server/blob/master/resources/buildConfigDefinition.js)
- add the parameter group type to `nestedOptionTypes` in [/resources/buildConfigDefinition.js](https://github.com/parse-community/parse-server/blob/master/resources/buildConfigDefinition.js)
For example, take a look at the existing Parse Server `security` parameter. It is a parameter group, because it has multiple sub-parameter such as `checkGroups`. Its interface is defined in [index.js][config-index] as `export interface SecurityOptions`. Therefore, the value to add to `nestedOptionTypes` would be `SecurityOptions`, the value to add to `nestedOptionEnvPrefix` would be `PARSE_SERVER_SECURITY_`.
3. Execute `npm run definitions` to automatically create the definitions in [/src/Options/Definitions.js][config-def] and [/src/Options/docs.js][config-docs].
4. Add parameter value validation in [/src/Config.js](https://github.com/parse-community/parse-server/blob/master/src/Config.js).
5. Add test cases to ensure the correct parameter value validation. Parse Server throws an error at launch if an invalid value is set for any configuration parameter.
6. Execute `npm run docs` to generate the documentation in the `/out` directory. Take a look at the documentation whether the description and formatting of the newly introduced parameters is satisfactory.
## Pull Request
For release automation, the title of pull requests needs to be written in a defined syntax. We loosely follow the [Conventional Commits](https://www.conventionalcommits.org) specification, which defines this syntax:
```
<type>: <summary>
```
The _type_ is the category of change that is made, possible types are:
- `feat` - add a new feature or improve an existing feature
- `fix` - fix a bug
- `refactor` - refactor code without impact on features or performance
- `build` - retry failing build and anything build process related
- `perf` - performance optimization
- `ci` - continuous integration
- `test` - tests
The _summary_ is a short change description in present tense, not capitalized, without period at the end. This summary will also be used as the changelog entry.
- It must be short and self-explanatory for a reader who does not see the details of the full pull request description
- It must not contain abbreviations, e.g. instead of `LQ` write `LiveQuery`
- It must use the correct product and feature names as referenced in the documentation, e.g. instead of `Cloud Validator` use `Cloud Function validation`
- In case of a breaking change, the summary must not contain duplicate information that is also in the [BREAKING CHANGE](#breaking-change) chapter of the pull request description. It must not contain a note that it is a breaking change, as this will be automatically flagged as such if the pull request description contains the BREAKING CHANGE chapter.
For example:
```
feat: add handle to door for easy opening
```
Currently, we are not making use of the commit _scope_, which would be written as `<type>(<scope>): <summary>`, that attributes a change to a specific part of the product.
### Breaking Change
If a pull request contains a braking change, the description of the pull request must contain a dedicated chapter at the bottom to indicate this. This is to assist the committer of the pull request to avoid merging a breaking change as non-breaking.
## Merging
The following guide is for anyone who merges a contributor pull request into the working branch, the working branch into a release branch, a release branch into another release branch, or any other direct commits such as hotfixes into release branches or the working branch.
- A contributor pull request must be merged into the working branch using `Squash and Merge`, to create a single commit message that describes the change.
- A release branch or the default branch must be merged into another release branch using `Merge Commit`, to preserve each individual commit message that describes its respective change.
- For changelog generation, only the commit message set when merging the pull request is relevant. The title and description of the GitHub pull request as authored by the contributor have no influence on the changelog generation. However, the title of the GitHub pull request should be used as the commit message. See the following chapters for considerations in special scenarios, e.g. merging a breaking change or reverting a commit.
### Breaking Change
If the pull request contains a breaking change, the commit message must contain the phrase `BREAKING CHANGE`, capitalized and without any formatting, followed by a short description of the breaking change and ideally how the developer should address it, all in a single line. This line should contain more details focusing on the "breaking” aspect of the change and is intended to assist the developer in adapting. Keep it concise, as it will become part of the changelog entry, for example:
```
fix: remove handle from door
BREAKING CHANGE: You cannot open the door anymore by using a handle. See the [#migration guide](http://example.com) for more details.
```
Keep in mind that in a repository with release automation, merging such a commit message will trigger a release with a major version increment.
### Reverting
If the commit reverts a previous commit, use the prefix `revert:`, followed by the header of the reverted commit. In the body of the commit message add `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted. For example:
```
revert: fix: remove handle from door
This reverts commit 1234567890abcdef.
```
⚠️ A `revert` prefix will *always* trigger a release. Generally, a commit that did not trigger a release when it was initially merged should also not trigger a release when it is reverted. For example, do not use the `revert` prefix when reverting a commit that has a `ci` prefix:
```
ci: add something
```
is reverted with:
```
ci: remove something
```
instead of:
```
revert: ci: add something
This reverts commit 1234567890abcdef.
```
## Releasing
### General Considerations
- The `package-lock.json` file has to be deleted and recreated by npm from scratch in regular intervals using the `npm i` command. It is not enough to only update the file via automated security pull requests (e.g. dependabot, snyk), that can create inconsistencies between sub-devependencies of a dependency and increase the chances of vulnerabilities. The file should be recreated once every release cycle which is usually monthly.
### Major Release / Long-Term-Support
Long-Term-Support (LTS) is provided for the previous Parse Server major version. For example, Parse Server 4.x will receive security updates until Parse Server 5.x is superseded by Parse Server 6.x and becomes the new LTS version. While the current major version is published on branch `release`, a LTS version is published on branch `release-#.x.x`, for example `release-4.x.x` for the Parse Server 4.x LTS branch.
#### Preparing Release
The following changes are done in the `alpha` branch, before publishing the last `beta` version that will eventually become the major release. This way the changes trickle naturally through all branches and code consistency is ensured among branches.
- Make sure all [deprecations](https://github.com/parse-community/parse-server/blob/alpha/DEPRECATIONS.md) are reflected in code, old code is removed and the deprecations table is updated.
- Add the future LTS branch `release-#.x.x` to the branch list in [release.config.js](https://github.com/parse-community/parse-server/blob/alpha/release.config.js) so that the branch will later be recognized for release automation.
#### Publishing Release
1. Create LTS branch `release-#.x.x` off the latest version tag on `release` branch.
2. Create temporary branch `build-release` off branch `beta` and create a pull request with `release` as the base branch.
3. Merge branch `build-release` into `release`. Given that there will be breaking changes, a new major release will be created. In the unlikely case that there have been no breaking changes between the previous major release and the upcoming release, a major version increment has to be triggered manually. See the docs of the release automation framework for how to do that.
## Versioning
> The following versioning system is applied since Parse Server 5.0.0 and does not necessarily apply to previous releases.
Parse Server follows [semantic versioning](https://semver.org) with a flavor of [calendric versioning](https://calver.org). Semantic versioning makes Parse Server easy to upgrade because breaking changes only occur in major releases. Calendric versioning gives an additional sense of how old a Parse Server release is and allows for Long-Term Support of previous major releases.
- The `major` version increments with the first release of every year and may include changes that are *not backwards compatible*.
- The `minor` version increments during the year and may include new features or improvements of existing features that are backwards compatible.
- The `patch` version increments during the year and may include bug fixes that are backwards compatible.
- The `pre-release-label` is optional for pre-release versions such as:
- `-alpha` (likely to contain bugs, likely to change in features until release)
- `-beta` (likely to contain bugs, no change in features until release)
- The `[pre-release-increment]` is a number that increments with every new version of a pre-release
Exceptions:
- The `major` version may increment during the year in the unlikely event that a breaking change is so urgent that it cannot wait for the next yearly release. An example would be a vulnerability fix that leads to an unavoidable breaking change. However, security requirements depend on the application and not every vulnerability may affect every deployment, depending on the features used. Therefore we usually prefer to deprecate insecure functionality and introduce the breaking change following our [deprecation policy](#deprecation-policy).
## Code of Conduct
This project adheres to the [Contributor Covenant Code of Conduct](https://github.com/parse-community/parse-server/blob/master/CODE_OF_CONDUCT.md). By participating, you are expected to honor this code.
The following is a list of deprecations, according to the [Deprecation Policy](https://github.com/parse-community/parse-server/blob/master/CONTRIBUTING.md#deprecation-policy). After a feature becomes deprecated, and giving developers time to adapt to the change, the deprecated feature will eventually be removed, leading to a breaking change. Developer feedback during the deprecation period may postpone or even revoke the introduction of the breaking change.
| ID | Change | Issue | Deprecation [ℹ️][i_deprecation] | Planned Removal [ℹ️][i_removal] | Status [ℹ️][i_status] | Notes |
[i_deprecation]: ## "The version and date of the deprecation."
[i_removal]: ## "The version and date of the planned removal."
[i_status]: ## "The current status of the deprecation: deprecated (the feature is deprecated and still available), removed (the deprecated feature has been removed and is unavailable), retracted (the deprecation has been retracted and the feature will not be removed."
<a href="#backers"><img alt="Backers on Open Collective" src="https://opencollective.com/parse-server/backers/badge.svg" /></a>
<a href="#sponsors"><img alt="Sponsors on Open Collective" src="https://opencollective.com/parse-server/sponsors/badge.svg" /></a>
</p>
<br>
Parse Server works with the Express web application framework. It can be added to existing web applications, or run by itself.
Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Parse Server works with the Express web application framework. It can be added to existing web applications, or run by itself.
The full documentation for Parse Server is available in the [wiki](https://github.com/parse-community/parse-server/wiki). The [Parse Server guide](http://docs.parseplatform.org/parse-server/guide/) is a good place to get started. An [API reference](http://parseplatform.org/parse-server/api/) and [Cloud Code guide](https://docs.parseplatform.org/cloudcode/guide/) are also available. If you're interested in developing for Parse Server, the [Development guide](http://docs.parseplatform.org/parse-server/guide/#development-guide) will help you get set up.
---
A big *thank you* 🙏 to our [sponsors](#sponsors) and [backers](#backers) who support the development of Parse Platform!
- [Customizing your GraphQL Schema](#customizing-your-graphql-schema)
- [Learning more](#learning-more)
- [Upgrading to 3.0.0](#upgrading-to-300)
- [Support](#support)
- [Ride the Bleeding Edge](#want-to-ride-the-bleeding-edge)
- [Want to ride the bleeding edge?](#want-to-ride-the-bleeding-edge)
- [Contributing](#contributing)
- [Contributors](#contributors)
- [Sponsors](#sponsors)
- [Backers](#backers)
# Getting Started
The fastest and easiest way to get started is to run MongoDB and Parse Server locally.
@@ -79,9 +104,41 @@ The fastest and easiest way to get started is to run MongoDB and Parse Server lo
Before you start make sure you have installed:
- [NodeJS](https://www.npmjs.com/) that includes `npm`
- [MongoDB](https://www.mongodb.com/) or [PostgreSQL](https://www.postgresql.org/)
- [MongoDB](https://www.mongodb.com/) or [PostgreSQL](https://www.postgresql.org/)(with [PostGIS](https://postgis.net) 2.2.0 or higher)
- Optionally [Docker](https://www.docker.com/)
### Compatibility
#### Node.js
Parse Server is continuously tested with the most recent releases of Node.js to ensure compatibility. We follow the [Node.js Long Term Support plan](https://github.com/nodejs/Release) and only test against versions that are officially supported and have not reached their end-of-life date.
| Version | Latest Version | End-of-Life | Compatible |
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 only test against versions that are officially supported and have not reached their end-of-life date.
| Version | Latest Version | End-of-Life | Compatible |
Parse Server is continuously tested with the most recent releases of PostgreSQL and PostGIS to ensure compatibility, using [PostGIS docker images](https://registry.hub.docker.com/r/postgis/postgis/tags?page=1&ordering=last_updated). We follow the [PostgreSQL support schedule](https://www.postgresql.org/support/versioning) and [PostGIS support schedule](https://www.postgis.net/eol_policy/) and only test against versions that are officially supported and have not reached their end-of-life date. Due to the extensive PostgreSQL support duration of 5 years, Parse Server drops support if a version is older than 3.5 years and a newer version has been available for at least 2.5 years.
| Version | PostGIS Version | End-of-Life | Parse Server Support End | Compatible |
***Note:*** *If you want to use [Cloud Code](https://docs.parseplatform.org/cloudcode/guide/), add `-v cloud-code-vol:/parse-server/cloud --cloud /parse-server/cloud/main.js` to the command above. Make sure `main.js` is in the `cloud-code-vol` directory before starting Parse Server.*
You can use any arbitrary string as your application id and master key. These will be used by your clients to authenticate with the Parse Server.
That's it! You are now running a standalone version of Parse Server on your machine.
**Using a remote MongoDB?** Pass the `--databaseURI DATABASE_URI` parameter when starting `parse-server`. Learn more about configuring Parse Server [here](#configuration). For a full list of available options, run `parse-server --help`.
### Saving your first object
### Saving an Object
Now that you're running Parse Server, it is time to save your first object. We'll use the [REST API](http://docs.parseplatform.org/rest/guide), but you can easily do the same using any of the [Parse SDKs](http://parseplatform.org/#sdks). Run the following:
@@ -172,7 +237,7 @@ $ curl -X GET \
To learn more about using saving and querying objects on Parse Server, check out the [Parse documentation](http://docs.parseplatform.org).
### Connect your app to Parse Server
### Connect an SDK
Parse provides SDKs for all the major platforms. Refer to the Parse Server guide to [learn how to connect your app to Parse Server](https://docs.parseplatform.org/parse-server/guide/#using-parse-sdks-with-parse-server).
@@ -180,7 +245,7 @@ Parse provides SDKs for all the major platforms. Refer to the Parse Server guide
Once you have a better understanding of how the project works, please refer to the [Parse Server wiki](https://github.com/parse-community/parse-server/wiki) for in-depth guides to deploy Parse Server to major infrastructure providers. Read on to learn more about additional ways of running Parse Server.
### Parse Server Sample Application
### Sample Application
We have provided a basic [Node.js application](https://github.com/parse-community/parse-server-example) that uses the Parse Server module on Express and can be easily deployed to various infrastructure providers:
@@ -191,7 +256,7 @@ We have provided a basic [Node.js application](https://github.com/parse-communit
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).
## Configuration
# Configuration
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.
For the 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).
### Basic options
## Basic Options
*`appId`**(required)** - The application id to host with this server instance. You can use any arbitrary string. For migrated apps, this should match your hosted Parse app.
*`masterKey`**(required)** - The master key to use for overriding ACL security. You can use any arbitrary string. Keep it secret! For migrated apps, this should match your hosted Parse app.
@@ -237,9 +302,9 @@ For the full list of available options, run `parse-server --help` or take a look
*`port` - The default port is 1337, specify this parameter to use a different port.
*`serverURL` - URL to your Parse Server (don't forget to specify http:// or https://). This URL will be used when making requests to Parse Server from Cloud Code.
*`cloud` - The absolute path to your cloud code `main.js` file.
*`push` - Configuration options for APNS and GCM push. See the [Push Notifications quick start](http://docs.parseplatform.org/parse-server/guide/#push-notifications_push-notifications-quick-start).
*`push` - Configuration options for APNS and GCM push. See the [Push Notifications quick start](https://docs.parseplatform.org/parse-server/guide/#push-notifications-quick-start).
### Client key options
## Client Key Options
The client keys used with Parse are no longer necessary with Parse Server. If you wish to still require them, perhaps to be able to refuse access to older clients, you can set the keys at initialization time. Setting any of these keys will require all requests to provide one of the configured keys.
@@ -248,76 +313,34 @@ The client keys used with Parse are no longer necessary with Parse Server. If yo
*`restAPIKey`
*`dotNetKey`
### Email verification and password reset
## Email Verification and Password Reset
Verifying user email addresses and enabling password reset via email requires an email adapter. As part of the `parse-server` package we provide an adapter for sending email through Mailgun. To use it, sign up for Mailgun, and add this to your initialization code:
Verifying user email addresses and enabling password reset via email requires an email adapter. There are many email adapters provided and maintained by the community. The following is an example configuration with an example email adapter. See the [Parse Server Options](https://parseplatform.org/parse-server/api/master/ParseServerOptions.html) for more details and a full list of available options.
```js
varserver=ParseServer({
constserver=ParseServer({
...otherOptions,
// Enable email verification
verifyUserEmails:true,
// if `verifyUserEmails` is `true` and
// if `emailVerifyTokenValidityDuration` is `undefined` then
// email verify token never expires
// else
// email verify token expires after `emailVerifyTokenValidityDuration`
//
// `emailVerifyTokenValidityDuration` defaults to `undefined`
emailVerifyTokenValidityDuration:2*60*60,// in seconds (2 hours = 7200 seconds)
// Set email verification token validity to 2 hours
emailVerifyTokenValidityDuration:2*60*60,
// set preventLoginWithUnverifiedEmail to false to allow user to login without verifying their email
// set preventLoginWithUnverifiedEmail to true to prevent user from login if their email is not verified
preventLoginWithUnverifiedEmail:false,// defaults to false
// The public URL of your app.
// This will appear in the link that is used to verify email addresses and reset passwords.
// Set the mount path as it is in serverURL
publicServerURL:'https://example.com/parse',
// Your apps name. This will appear in the subject and body of the emails that are sent.
appName:'Parse App',
// The email adapter
// Set email adapter
emailAdapter:{
module:'@parse/simple-mailgun-adapter',
module:'example-mail-adapter',
options:{
// The address that your emails come from
fromAddress:'parse@example.com',
// Your domain from mailgun.com
domain:'example.com',
// Your API key from mailgun.com
apiKey:'key-mykey',
// Additional adapter options
...mailAdapterOptions
}
},
// account lockout policy setting (OPTIONAL) - defaults to undefined
// if the account lockout policy is set and there are more than `threshold` number of failed login attempts then the `login` api call returns error code `Parse.Error.OBJECT_NOT_FOUND` with error message `Your account is locked due to multiple failed login attempts. Please try again after <duration> minute(s)`. After `duration` minutes of no login attempts, the application will allow the user to try login again.
accountLockout:{
duration:5,// duration policy setting determines the number of minutes that a locked-out account remains locked out before automatically becoming unlocked. Set it to a value greater than 0 and less than 100000.
threshold:3,// threshold policy setting determines the number of failed sign-in attempts that will cause a user account to be locked. Set it to an integer value greater than 0 and less than 1000.
},
// optional settings to enforce password policies
passwordPolicy:{
// Two optional settings to enforce strong passwords. Either one or both can be specified.
// If both are specified, both checks must pass to accept the password
// 1. a RegExp object or a regex string representing the pattern to enforce
validatorPattern:/^(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.{8,})/,// enforce password with at least 8 char with at least 1 lower case, 1 upper case and 1 digit
// 2. a callback function to be invoked to validate the password
validationError:'Password must contain at least 1 digit.'// optional error message to be sent instead of the default "Password does not meet the Password Policy requirements." message.
doNotAllowUsername:true,// optional setting to disallow username in passwords
maxPasswordAge:90,// optional setting in days for password expiry. Login fails if user does not reset the password within this period after signup/last reset.
maxPasswordHistory:5,// optional setting to prevent reuse of previous n passwords. Maximum value that can be specified is 20. Not specifying it or specifying 0 will not enforce history.
//optional setting to set a validity duration for password reset links (in seconds)
resetTokenValidityDuration:24*60*60,// expire after 24 hours
}
});
```
You can also use other email adapters contributed by the community such as:
- [parse-smtp-template (Multi Language and Multi Template)](https://www.npmjs.com/package/parse-smtp-template)
Email adapters contributed by the community:
- [parse-server-api-mail-adapter](https://www.npmjs.com/package/parse-server-api-mail-adapter) (localization, templates, universally supports any email provider)
Set a password and account policy that meets your security requirements. The following is an example configuration. See the [Parse Server Options](https://parseplatform.org/parse-server/api/master/ParseServerOptions.html) for more details and a full list of available options.
```js
constserver=ParseServer({
...otherOptions,
// The account lock policy
accountLockout:{
// Lock the account for 5 minutes.
duration:5,
// Lock an account after 3 failed log-in attempts
threshold:3,
// Unlock the account after a successful password reset
unlockOnPasswordReset:true,
},
// The password policy
passwordPolicy:{
// Enforce a password of at least 8 characters which contain at least 1 lower case, 1 upper case and 1 digit
// Do not allow the username as part of the password
doNotAllowUsername:true,
// Do not allow to re-use the last 5 passwords when setting a new password
maxPasswordHistory:5,
},
});
```
## Custom Routes
**Caution, this is an experimental feature that may not be appropriate for production.**
Custom routes allow to build user flows with webpages, similar to the existing password reset and email verification features. Custom routes are defined with the `pages` option in the Parse Server configuration:
### Example
```js
constapi=newParseServer({
...otherOptions,
pages:{
enableRouter:true,// Enables the experimental feature; required for custom routes
customRoutes:[{
method:'GET',
path:'custom_route',
handler:asyncrequest=>{
// custom logic
// ...
// then, depending on the outcome, return a HTML file as response
return{file:'custom_page.html'};
}
}]
}
}
```
The above route can be invoked by sending a `GET` request to:
The `handler` receives the `request` and returns a `custom_page.html` webpage from the `pages.pagesPath` directory as response. The advantage of building a custom route this way is that it automatically makes use of Parse Server's built-in capabilities, such as [page localization](#pages) and [dynamic placeholders](#dynamic-placeholders).
### Reserved Paths
The following paths are already used by Parse Server's built-in features and are therefore not available for custom routes. Custom routes with an identical combination of `path` and `method` are ignored.
| `pages` | yes | `Object` | `undefined` | - | `PARSE_SERVER_PAGES` | The options for pages such as password reset and email verification. |
| `pages.enableRouter` | yes | `Boolean` | `false` | - | `PARSE_SERVER_PAGES_ENABLE_ROUTER` | Is `true` if the pages router should be enabled; this is required for any of the pages options to take effect. **Caution, this is an experimental feature that may not be appropriate for production.** |
| `pages.customRoutes` | yes | `Array` | `[]` | - | `PARSE_SERVER_PAGES_CUSTOM_ROUTES` | The custom routes. The routes are added in the order they are defined here, which has to be considered since requests traverse routes in an ordered manner. Custom routes are traversed after build-in routes such as password reset and email verification. |
| `pages.customRoutes.method` | | `String` | - | `GET`, `POST` | - | The HTTP method of the custom route. |
| `pages.customRoutes.path` | | `String` | - | `custom_page` | - | The path of the custom route. Note that the same path can used if the `method` is different, for example a path `custom_page` can have two routes, a `GET` and `POST` route, which will be invoked depending on the HTTP request method. |
| `pages.customRoutes.handler` | | `AsyncFunction` | - | `async () => { ... }` | - | The route handler that is invoked when the route matches the HTTP request. If the handler does not return a page, the request is answered with a 404 `Not found.` response. |
## Custom Pages
It’s possible to change the default pages of the app and redirect the user to another path or domain.
@@ -349,7 +456,7 @@ var server = ParseServer({
})
```
### Using environment variables to configure Parse Server
## Using Environment Variables
You may configure the Parse Server using environment variables:
For the full list of configurable environment variables, run `parse-server --help` or take a look at [Parse Server Configuration](https://github.com/parse-community/parse-server/blob/master/src/Options/Definitions.js).
### Available Adapters
## Available Adapters
All official adapters are distributed as scoped pacakges on [npm (@parse)](https://www.npmjs.com/search?q=scope%3Aparse).
All official adapters are distributed as scoped packages on [npm (@parse)](https://www.npmjs.com/search?q=scope%3Aparse).
Some well maintained adapters are also available on the [Parse Server Modules](https://github.com/parse-server-modules) organization.
You can also find more adapters maintained by the community by searching on [npm](https://www.npmjs.com/search?q=parse-server%20adapter&page=1&ranking=optimal).
### Configuring File Adapters
## Configuring File Adapters
Parse Server allows developers to choose from several options when hosting files:
*`GridFSBucketAdapter`, which is backed by MongoDB;
*`S3Adapter`, which is backed by [Amazon S3](https://aws.amazon.com/s3/); or
*`GCSAdapter`, which is backed by [Google Cloud Storage](https://cloud.google.com/storage/)
*`GridFSBucketAdapter` - which is backed by MongoDB
*`S3Adapter` - which is backed by [Amazon S3](https://aws.amazon.com/s3/)
*`GCSAdapter` - which is backed by [Google Cloud Storage](https://cloud.google.com/storage/)
*`FSAdapter` - local file storage
`GridFSBucketAdapter` is used by default and requires no setup, but if you're interested in using S3 or Google Cloud Storage, additional configuration information is available in the [Parse Server guide](http://docs.parseplatform.org/parse-server/guide/#configuring-file-adapters).
`GridFSBucketAdapter` is used by default and requires no setup, but if you're interested in using Amazon S3, Google Cloud Storage, or local file storage, additional configuration information is available in the [Parse Server guide](http://docs.parseplatform.org/parse-server/guide/#configuring-file-adapters).
### Logging
## Idempotency Enforcement
**Caution, this is an experimental feature that may not be appropriate for production.**
This feature deduplicates identical requests that are received by Parse Server multiple times, typically due to network issues or network adapter access restrictions on mobile operating systems.
Identical requests are identified by their request header `X-Parse-Request-Id`. Therefore a client request has to include this header for deduplication to be applied. Requests that do not contain this header cannot be deduplicated and are processed normally by Parse Server. This means rolling out this feature to clients is seamless as Parse Server still processes requests without this header when this feature is enabled.
> This feature needs to be enabled on the client side to send the header and on the server to process the header. Refer to the specific Parse SDK docs to see whether the feature is supported yet.
Deduplication is only done for object creation and update (`POST` and `PUT` requests). Deduplication is not done for object finding and deletion (`GET` and `DELETE` requests), as these operations are already idempotent by definition.
### Configuration example <!-- omit in toc -->
```
let api = new ParseServer({
idempotencyOptions: {
paths: [".*"], // enforce for all requests
ttl: 120 // keep request IDs for 120s
}
}
```
### Parameters <!-- omit in toc -->
| Parameter | Optional | Type | Default value | Example values | Environment variable | Description |
| `idempotencyOptions` | yes | `Object` | `undefined` | | PARSE_SERVER_EXPERIMENTAL_IDEMPOTENCY_OPTIONS | Setting this enables idempotency enforcement for the specified paths. |
| `idempotencyOptions.paths` | yes | `Array<String>` | `[]` | `.*` (all paths, includes the examples below), <br>`functions/.*` (all functions), <br>`jobs/.*` (all jobs), <br>`classes/.*` (all classes), <br>`functions/.*` (all functions), <br>`users` (user creation / update), <br>`installations` (installation creation / update) | PARSE_SERVER_EXPERIMENTAL_IDEMPOTENCY_PATHS | An array of path patterns that have to match the request path for request deduplication to be enabled. The mount path must not be included, for example to match the request path `/parse/functions/myFunction` specify the path pattern `functions/myFunction`. A trailing slash of the request path is ignored, for example the path pattern `functions/myFunction` matches both `/parse/functions/myFunction` and `/parse/functions/myFunction/`. |
| `idempotencyOptions.ttl` | yes | `Integer` | `300` | `60` (60 seconds) | PARSE_SERVER_EXPERIMENTAL_IDEMPOTENCY_TTL | The duration in seconds after which a request record is discarded from the database. Duplicate requests due to network issues can be expected to arrive within milliseconds up to several seconds. This value must be greater than `0`. |
### Postgres <!-- omit in toc -->
To use this feature in Postgres, you will need to create a cron job using [pgAdmin](https://www.pgadmin.org/docs/pgadmin4/development/pgagent_jobs.html) or similar to call the Postgres function `idempotency_delete_expired_records()` that deletes expired idempotency records. You can find an example script below. Make sure the script has the same privileges to log into Postgres as Parse Server.
**Caution, this is an experimental feature that may not be appropriate for production.**
Custom pages as well as feature pages (e.g. password reset, email verification) can be localized with the `pages` option in the Parse Server configuration:
```js
constapi=newParseServer({
...otherOptions,
pages:{
enableRouter:true,// Enables the experimental feature; required for localization
enableLocalization:true,
}
}
```
Localization is achieved by matching a request-supplied `locale` parameter with localized page content. The locale can be supplied in either the request query, body or header with the following keys:
- query: `locale`
- body: `locale`
- header: `x-parse-page-param-locale`
For example, a password reset link with the locale parameter in the query could look like this:
- Localization is only available for pages in the pages directory as set with `pages.pagesPath`.
- Localization for feature pages (e.g. password reset, email verification) is disabled if `pages.customUrls` are set, even if the custom URLs point to the pages within the pages path.
- Only `.html` files are considered for localization when localizing custom pages.
Pages can be localized in two ways:
#### Localization with Directory Structure
Pages are localized by using the corresponding file in the directory structure where the files are placed in subdirectories named after the locale or language. The file in the base directory is the default file.
**Example Directory Structure:**
```js
root/
├──public/// pages base path
│├──example.html// default file
│└──de/// de language folder
││└──example.html// de localized file
│└──de-AT/// de-AT locale folder
││└──example.html// de-AT localized file
```
Files are matched with the locale in the following order:
1. Locale match, e.g. locale `de-AT` matches file in folder `de-AT`.
1. Language match, e.g. locale `de-CH` matches file in folder `de`.
1. Default; file in base folder is returned.
**Configuration Example:**
```js
constapi=newParseServer({
...otherOptions,
pages:{
enableRouter:true,// Enables the experimental feature; required for localization
enableLocalization:true,
customUrls:{
passwordReset:'https://example.com/page.html'
}
}
}
```
Pros:
- All files are complete in their content and can be easily opened and previewed by viewing the file in a browser.
Cons:
- In most cases, a localized page differs only slightly from the default page, which could cause a lot of duplicate code that is difficult to maintain.
#### Localization with JSON Resource
Pages are localized by adding placeholders in the HTML files and providing a JSON resource that contains the translations to fill into the placeholders.
**Example Directory Structure:**
```js
root/
├──public/// pages base path
│├──example.html// the page containing placeholders
├──private/// folder outside of public scope
│└──translations.json// JSON resource file
```
The JSON resource file loosely follows the [i18next](https://github.com/i18next/i18next) syntax, which is a syntax that is often supported by translation platforms, making it easy to manage translations, exporting them for use in Parse Server, and even to automate this workflow.
**Example JSON Content:**
```json
{
"en":{// resource for language `en` (English)
"translation":{
"greeting":"Hello!"
}
},
"de":{// resource for language `de` (German)
"translation":{
"greeting":"Hallo!"
}
}
"de-AT":{// resource for locale `de-AT` (Austrian German)
"translation":{
"greeting":"Servus!"
}
}
}
```
**Configuration Example:**
```js
constapi=newParseServer({
...otherOptions,
pages:{
enableRouter:true,// Enables the experimental feature; required for localization
- There is only one HTML file to maintain that contains the placeholders that are filled with the translations according to the locale.
Cons:
- Files cannot be easily previewed by viewing the file in a browser because the content contains only placeholders and even HTML or CSS changes may be dynamically applied, e.g. when a localization requires a Right-To-Left layout direction.
- Style and other fundamental layout changes may be more difficult to apply.
#### Dynamic placeholders
In addition to feature related default parameters such as `appId` and the translations provided via JSON resource, it is possible to define custom dynamic placeholders as part of the router configuration. This works independently of localization and, also if `enableLocalization` is disabled.
**Configuration Example:**
```js
constapi=newParseServer({
...otherOptions,
pages:{
enableRouter:true,// Enables the experimental feature; required for localization
placeholders:{
exampleKey:'exampleValue'
}
}
}
```
The placeholders can also be provided as function or as async function, with the `locale` and other feature related parameters passed through, to allow for dynamic placeholder values:
```js
constapi=newParseServer({
...otherOptions,
pages:{
enableRouter:true,// Enables the experimental feature; required for localization
placeholders:async(params)=>{
constvalue=awaitdoSomething(params.locale);
return{
exampleKey:value
};
}
}
}
```
#### Reserved Keys
The following parameter and placeholder keys are reserved because they are used related to features such as password reset or email verification. They should not be used as translation keys in the JSON resource or as manually defined placeholder keys in the configuration: `appId`, `appName`, `email`, `error`, `locale`, `publicServerUrl`, `token`, `username`.
#### Parameters
| Parameter | Optional | Type | Default value | Example values | Environment variable | Description |
| `pages` | yes | `Object` | `undefined` | - | `PARSE_SERVER_PAGES` | The options for pages such as password reset and email verification. |
| `pages.enableRouter` | yes | `Boolean` | `false` | - | `PARSE_SERVER_PAGES_ENABLE_ROUTER` | Is `true` if the pages router should be enabled; this is required for any of the pages options to take effect. **Caution, this is an experimental feature that may not be appropriate for production.** |
| `pages.enableLocalization` | yes | `Boolean` | `false` | - | `PARSE_SERVER_PAGES_ENABLE_LOCALIZATION` | Is true if pages should be localized; this has no effect on custom page redirects. |
| `pages.localizationJsonPath` | yes | `String` | `undefined` | `./private/translations.json` | `PARSE_SERVER_PAGES_LOCALIZATION_JSON_PATH` | The path to the JSON file for localization; the translations will be used to fill template placeholders according to the locale. |
| `pages.localizationFallbackLocale` | yes | `String` | `en` | `en`, `en-GB`, `default` | `PARSE_SERVER_PAGES_LOCALIZATION_FALLBACK_LOCALE` | The fallback locale for localization if no matching translation is provided for the given locale. This is only relevant when providing translation resources via JSON file. |
| `pages.placeholders` | yes | `Object`, `Function`, `AsyncFunction` | `undefined` | `{ exampleKey: 'exampleValue' }` | `PARSE_SERVER_PAGES_PLACEHOLDERS` | The placeholder keys and values which will be filled in pages; this can be a simple object or a callback function. |
| `pages.forceRedirect` | yes | `Boolean` | `false` | - | `PARSE_SERVER_PAGES_FORCE_REDIRECT` | Is `true` if responses should always be redirects and never content, `false` if the response type should depend on the request type (`GET` request -> content response; `POST` request -> redirect response). |
| `pages.pagesPath` | yes | `String` | `./public` | `./files/pages`, `../../pages` | `PARSE_SERVER_PAGES_PAGES_PATH` | The path to the pages directory; this also defines where the static endpoint `/apps` points to. |
| `pages.pagesEndpoint` | yes | `String` | `apps` | - | `PARSE_SERVER_PAGES_PAGES_ENDPOINT` | The API endpoint for the pages. |
| `pages.customUrls` | yes | `Object` | `{}` | `{ passwordReset: 'https://example.com/page.html' }` | `PARSE_SERVER_PAGES_CUSTOM_URLS` | The URLs to the custom pages |
| `pages.customUrls.passwordReset` | yes | `String` | `password_reset.html` | - | `PARSE_SERVER_PAGES_CUSTOM_URL_PASSWORD_RESET` | The URL to the custom page for password reset. |
| `pages.customUrls.passwordResetSuccess` | yes | `String` | `password_reset_success.html` | - | `PARSE_SERVER_PAGES_CUSTOM_URL_PASSWORD_RESET_SUCCESS` | The URL to the custom page for password reset -> success. |
| `pages.customUrls.passwordResetLinkInvalid` | yes | `String` | `password_reset_link_invalid.html` | - | `PARSE_SERVER_PAGES_CUSTOM_URL_PASSWORD_RESET_LINK_INVALID` | The URL to the custom page for password reset -> link invalid. |
| `pages.customUrls.emailVerificationSuccess` | yes | `String` | `email_verification_success.html` | - | `PARSE_SERVER_PAGES_CUSTOM_URL_EMAIL_VERIFICATION_SUCCESS` | The URL to the custom page for email verification -> success. |
| `pages.customUrls.emailVerificationSendFail` | yes | `String` | `email_verification_send_fail.html` | - | `PARSE_SERVER_PAGES_CUSTOM_URL_EMAIL_VERIFICATION_SEND_FAIL` | The URL to the custom page for email verification -> link send fail. |
| `pages.customUrls.emailVerificationSendSuccess` | yes | `String` | `email_verification_send_success.html` | - | `PARSE_SERVER_PAGES_CUSTOM_URL_EMAIL_VERIFICATION_SEND_SUCCESS` | The URL to the custom page for email verification -> resend link -> success. |
| `pages.customUrls.emailVerificationLinkInvalid` | yes | `String` | `email_verification_link_invalid.html` | - | `PARSE_SERVER_PAGES_CUSTOM_URL_EMAIL_VERIFICATION_LINK_INVALID` | The URL to the custom page for email verification -> link invalid. |
| `pages.customUrls.emailVerificationLinkExpired` | yes | `String` | `email_verification_link_expired.html` | - | `PARSE_SERVER_PAGES_CUSTOM_URL_EMAIL_VERIFICATION_LINK_EXPIRED` | The URL to the custom page for email verification -> link expired. |
### Notes <!-- omit in toc -->
- In combination with the [Parse Server API Mail Adapter](https://www.npmjs.com/package/parse-server-api-mail-adapter) Parse Server provides a fully localized flow (emails -> pages) for the user. The email adapter sends a localized email and adds a locale parameter to the password reset or email verification link, which is then used to respond with localized pages.
## Logging
Parse Server will, by default, log:
* to the console
@@ -398,24 +754,26 @@ Logs are also viewable in Parse Dashboard.
**Want to log each request and response?** Set the `VERBOSE` environment variable when starting `parse-server`. Usage :- `VERBOSE='1' parse-server --appId APPLICATION_ID --masterKey MASTER_KEY`
**Want logs to be in placed in a different folder?** Pass the `PARSE_SERVER_LOGS_FOLDER` environment variable when starting `parse-server`. Usage :- `PARSE_SERVER_LOGS_FOLDER='<path-to-logs-folder>' parse-server --appId APPLICATION_ID --masterKey MASTER_KEY`
**Want logs to be placed in a different folder?** Pass the `PARSE_SERVER_LOGS_FOLDER` environment variable when starting `parse-server`. Usage :- `PARSE_SERVER_LOGS_FOLDER='<path-to-logs-folder>' parse-server --appId APPLICATION_ID --masterKey MASTER_KEY`
**Want to log specific levels?** Pass the `logLevel` parameter when starting `parse-server`. Usage :- `parse-server --appId APPLICATION_ID --masterKey MASTER_KEY --logLevel LOG_LEVEL`
**Want new line delimited JSON error logs (for consumption by CloudWatch, Google Cloud Logging, etc)?** Pass the `JSON_LOGS` environment variable when starting `parse-server`. Usage :- `JSON_LOGS='1' parse-server --appId APPLICATION_ID --masterKey MASTER_KEY`
# Live Queries
# Deprecations
See the [Deprecation Plan](https://github.com/parse-community/parse-server/blob/master/DEPRECATIONS.md) for an overview of deprecations and planned breaking changes.
# Live Query
Live queries are meant to be used in real-time reactive applications, where just using the traditional query paradigm could cause several problems, like increased response time and high network and server usage. Live queries should be used in cases where you need to continuously update a page with fresh data coming from the database, which often happens in (but is not limited to) online games, messaging clients and shared to-do lists.
Take a look at [Live Query Guide](https://docs.parseplatform.org/parse-server/guide/#live-queries), [Live Query Server Setup Guide](https://docs.parseplatform.org/parse-server/guide/#scalability) and [Live Query Protocol Specification](https://github.com/parse-community/parse-server/wiki/Parse-LiveQuery-Protocol-Specification). You can setup a standalone server or multiple instances for scalability (recommended).
# GraphQL (beta)
# GraphQL
[GraphQL](https://graphql.org/), developed by Facebook, is an open-source data query and manipulation language for APIs. In addition to the traditional REST API, Parse Server automatically generates a GraphQL API based on your current application schema. Parse Server also allows you to define your custom GraphQL queries and mutations, whose resolvers can be bound to your cloud code functions.
⚠️ The Parse GraphQL ```beta``` implementation is fully functional but discussions are taking place on how to improve it. So new versions of Parse Server can bring breaking changes to the current API.
***Note:*** *If you want to use [Cloud Code](https://docs.parseplatform.org/cloudcode/guide/), add `-v cloud-code-vol:/parse-server/cloud --cloud /parse-server/cloud/main.js` to the command above. Make sure `main.js` is in the `cloud-code-vol` directory before starting Parse Server.*
After starting the server, you can visit http://localhost:1337/playground in your browser to start playing with your GraphQL API.
***Note:*** Do ***NOT*** use --mountPlayground option in production. [Parse Dashboard](https://github.com/parse-community/parse-dashboard) has a built-in GraphQL Playground and it is the recommended option for production apps.
@@ -683,7 +1048,7 @@ To start creating your custom schema, you need to code a `schema.graphql` file a
### Creating your first custom query <!-- omit in toc -->
Use the code below for your `schema.graphql` and `main.js` files. Then restart your Parse Server.
@@ -735,18 +1100,6 @@ All the Cloud Code interfaces also have been updated to reflect those changes, a
We have written up a [migration guide](3.0.0.md), hoping this will help you transition to the next major release.
# Support
Please take a look at our [support document](https://github.com/parse-community/.github/blob/master/SUPPORT.md).
If you believe you've found an issue with Parse Server, make sure these boxes are checked before [reporting an issue](https://github.com/parse-community/parse-server/issues):
- [ ] You've met the [prerequisites](http://docs.parseplatform.org/parse-server/guide/#prerequisites).
- [ ] You're running the [latest version](https://github.com/parse-community/parse-server/releases) of Parse Server.
- [ ] You've searched through [existing issues](https://github.com/parse-community/parse-server/issues?utf8=%E2%9C%93&q=). Chances are that your issue has been reported or resolved before.
# Want to ride the bleeding edge?
It is recommend to use builds deployed npm for many reasons, but if you want to use
You can also use your own forks, and work in progress branches by specifying them:
@@ -821,3 +1174,7 @@ Support us with a monthly donation and help us continue our activities. [Become
-----
As of April 5, 2017, Parse, LLC has transferred this code to the parse-community organization, and will no longer be contributing to or distributing this code.
All vulnerabilities should be privately reported to either [Node Security](https://nodesecurity.io/report) or directly to us at the following address [security at parseplatform dot org](mailto:security@parseplatform.org)
You can use our PGP public key, which is also uploaded [here](hkp://pgp.mit.edu):
All vulnerabilities should be privately reported to us by going to [https://report.parseplatform.org](https://report.parseplatform.org). Alternatively, you can send an email to [security@parseplatform.org](mailto:security@parseplatform.org).
* security bump minimist from 1.2.5 to 1.2.6 ([#7884](https://github.com/parse-community/parse-server/issues/7884)) ([c5cf282](https://github.com/parse-community/parse-server/commit/c5cf282d11ffdc023764f8e7539a2bd6bc246fe1))
* sensitive keyword detection may produce false positives ([#7881](https://github.com/parse-community/parse-server/issues/7881)) ([0d6f9e9](https://github.com/parse-community/parse-server/commit/0d6f9e951d9e186e95e96d8869066ce7022bad02))
* improved LiveQuery error logging with additional information ([#7837](https://github.com/parse-community/parse-server/issues/7837)) ([443a509](https://github.com/parse-community/parse-server/commit/443a5099059538d379fe491793a5871fcbb4f377))
* upgrade winston from 3.5.0 to 3.5.1 ([#7820](https://github.com/parse-community/parse-server/issues/7820)) ([4af253d](https://github.com/parse-community/parse-server/commit/4af253d1f8654a6f57b5137ad310cdacadc922cc))
* security upgrade follow-redirects from 1.14.7 to 1.14.8 ([#7801](https://github.com/parse-community/parse-server/issues/7801)) ([70088a9](https://github.com/parse-community/parse-server/commit/70088a95a78393da2a4ac68be81e63107747626a))
* server crash using GraphQL due to missing @apollo/client peer dependency ([#7787](https://github.com/parse-community/parse-server/issues/7787)) ([08089d6](https://github.com/parse-community/parse-server/commit/08089d6fcbb215412448ce7d92b21b9fe6c929f2))
* upgrade to MongoDB Node.js driver 4.x for MongoDB 5.0 support ([#7794](https://github.com/parse-community/parse-server/issues/7794)) ([f88aa2a](https://github.com/parse-community/parse-server/commit/f88aa2a62a533e5344d1c13dd38c5a0b283a480a))
### BREAKING CHANGES
* The MongoDB GridStore adapter has been removed. By default, Parse Server already uses GridFS, so if you do not manually use the GridStore adapter, you can ignore this change. ([f88aa2a](f88aa2a))
* bump node-fetch from 2.6.1 to 3.1.1 ([#7782](https://github.com/parse-community/parse-server/issues/7782)) ([9082351](https://github.com/parse-community/parse-server/commit/90823514113a1a085ebc818f7109b3fd7591346f))
* bump nanoid from 3.1.25 to 3.2.0 ([#7781](https://github.com/parse-community/parse-server/issues/7781)) ([f5f63bf](https://github.com/parse-community/parse-server/commit/f5f63bfc64d3481ed944ceb5e9f50b33dccd1ce9))
* security upgrade follow-redirects from 1.14.6 to 1.14.7 ([#7769](https://github.com/parse-community/parse-server/issues/7769)) ([8f5a861](https://github.com/parse-community/parse-server/commit/8f5a8618cfa7ed9a2a239a095abffa8f3fd8d31a))
* schema cache not cleared in some cases ([#7678](https://github.com/parse-community/parse-server/issues/7678)) ([5af6e5d](https://github.com/parse-community/parse-server/commit/5af6e5dfaa129b1a350afcba4fb381b21c4cc35d))
* support `postgresql` protocol in database URI ([#7757](https://github.com/parse-community/parse-server/issues/7757)) ([caf4a23](https://github.com/parse-community/parse-server/commit/caf4a2341f554b28e3918c53e7e897a3ca47bf8b))
* support relativeTime query constraint on Postgres ([#7747](https://github.com/parse-community/parse-server/issues/7747)) ([16b1b2a](https://github.com/parse-community/parse-server/commit/16b1b2a19714535ca805f2dbb3b561d8f6a519a7))
* node engine compatibility did not include node 16 ([#7739](https://github.com/parse-community/parse-server/issues/7739)) ([ea7c014](https://github.com/parse-community/parse-server/commit/ea7c01400f992a1263543706fe49b6174758a2d6))
* upgrade mime from 2.5.2 to 3.0.0 ([#7725](https://github.com/parse-community/parse-server/issues/7725)) ([f5ef98b](https://github.com/parse-community/parse-server/commit/f5ef98bde32083403c0e30a12162fcc1e52cac37))
* upgrade parse from 3.3.1 to 3.4.0 ([#7723](https://github.com/parse-community/parse-server/issues/7723)) ([d4c1f47](https://github.com/parse-community/parse-server/commit/d4c1f473073764cb0570c633fc4a30669c2ce889))
* unable to use objectId size higher than 19 on GraphQL API ([#7627](https://github.com/parse-community/parse-server/issues/7627)) ([ed86c80](https://github.com/parse-community/parse-server/commit/ed86c807721cc52a1a5a9dea0b768717eec269ed))
* add support for Node 16 ([#7707](https://github.com/parse-community/parse-server/issues/7707)) ([45cc58c](https://github.com/parse-community/parse-server/commit/45cc58c7e5e640a46c5d508019a3aa81242964b1))
### BREAKING CHANGES
* Removes official Node 15 support which has reached it end-of-life date. ([45cc58c](45cc58c))
* node engine range has no upper limit to exclude incompatible node versions ([#7692](https://github.com/parse-community/parse-server/issues/7692)) ([573558d](https://github.com/parse-community/parse-server/commit/573558d3adcbcc6222c92003829867e1a73eef94))
* refactor: allow ES import for cloud string if package type is module ([b64640c](https://github.com/parse-community/parse-server/commit/b64640c5705f733798783e68d216e957044ef23c))
* add support for Postgres 14 ([#7644](https://github.com/parse-community/parse-server/issues/7644)) ([090350a](https://github.com/parse-community/parse-server/commit/090350a7a0fac945394ca1cb24b290316ef06aa7))
* setting a field to null does not delete it via GraphQL API ([#7649](https://github.com/parse-community/parse-server/issues/7649)) ([626fad2](https://github.com/parse-community/parse-server/commit/626fad2e71017dcc62196c487de5f908fa43000b))
### BREAKING CHANGES
* To delete a field via the GraphQL API, the field value has to be set to `null`. Previously, setting a field value to `null` would save a null value in the database, which was not according to the [GraphQL specs](https://spec.graphql.org/June2018/#sec-Null-Value). To delete a file field use `file: null`, the previous way of using `file: { file: null }` has become obsolete. ([626fad2](626fad2))
- Improved schema caching through database real-time hooks. Reduces DB queries, decreases Parse Query execution time and fixes a potential schema memory leak. If multiple Parse Server instances connect to the same DB (for example behind a load balancer), set the [Parse Server Option](https://parseplatform.org/parse-server/api/master/ParseServerOptions.html) `databaseOptions.enableSchemaHooks: true` to enable this feature and keep the schema in sync across all instances. Failing to do so will cause a schema change to not propagate to other instances and re-syncing will only happen when these instances restart. The options `enableSingleSchemaCache` and `schemaCacheTTL` have been removed. To use this feature with MongoDB, a replica set cluster with [change stream](https://docs.mongodb.com/manual/changeStreams/#availability) support is required. (Diamond Lewis, SebC) [#7214](https://github.com/parse-community/parse-server/issues/7214)
- Added file upload restriction. File upload is now only allowed for authenticated users by default for improved security. To allow file upload also for Anonymous Users or Public, set the `fileUpload` parameter in the [Parse Server Options](https://parseplatform.org/parse-server/api/master/ParseServerOptions.html) (dblythy, Manuel Trezza) [#7071](https://github.com/parse-community/parse-server/pull/7071)
- Removed [parse-server-simple-mailgun-adapter](https://github.com/parse-community/parse-server-simple-mailgun-adapter) dependency; to continue using the adapter it has to be explicitly installed (Manuel Trezza) [#7321](https://github.com/parse-community/parse-server/pull/7321)
- Remove support for MongoDB 3.6 which has reached its End-of-Life date and PostgreSQL 10 (Manuel Trezza) [#7315](https://github.com/parse-community/parse-server/pull/7315)
- Remove support for Node 10 which has reached its End-of-Life date (Manuel Trezza) [#7314](https://github.com/parse-community/parse-server/pull/7314)
- Remove S3 Files Adapter from Parse Server, instead install separately as `@parse/s3-files-adapter` (Manuel Trezza) [#7324](https://github.com/parse-community/parse-server/pull/7324)
- Remove Session field `restricted`; the field was a code artifact from a feature that never existed in Open Source Parse Server; if you have been using this field for custom purposes, consider that for new Parse Server installations the field does not exist anymore in the schema, and for existing installations the field default value `false` will not be set anymore when creating a new session (Manuel Trezza) [#7543](https://github.com/parse-community/parse-server/pull/7543)
- ci: add node engine version check (Manuel Trezza) [#7574](https://github.com/parse-community/parse-server/pull/7574)
## Notable Changes
- Alphabetical ordered GraphQL API, improved GraphQL Schema cache system and fix GraphQL input reassign issue (Moumouls) [#7344](https://github.com/parse-community/parse-server/issues/7344)
- Added Parse Server Security Check to report weak security settings (Manuel Trezza, dblythy) [#7247](https://github.com/parse-community/parse-server/issues/7247)
- EXPERIMENTAL: Added new page router with placeholder rendering and localization of custom and feature pages such as password reset and email verification (Manuel Trezza) [#7128](https://github.com/parse-community/parse-server/pull/7128)
- EXPERIMENTAL: Added custom routes to easily customize flows for password reset, email verification or build entirely new flows (Manuel Trezza) [#7231](https://github.com/parse-community/parse-server/pull/7231)
- Added Deprecation Policy to govern the introduction of breaking changes in a phased pattern that is more predictable for developers (Manuel Trezza) [#7199](https://github.com/parse-community/parse-server/pull/7199)
- Add REST API endpoint `/loginAs` to create session of any user with master key; allows to impersonate another user. (GormanFletcher) [#7406](https://github.com/parse-community/parse-server/pull/7406)
- Add official support for MongoDB 5.0 (Manuel Trezza) [#7469](https://github.com/parse-community/parse-server/pull/7469)
- Added Parse Server Configuration `enforcePrivateUsers`, which will remove public access by default on new Parse.Users (dblythy) [#7319](https://github.com/parse-community/parse-server/pull/7319)
## Other Changes
- Support native mongodb syntax in aggregation pipelines (Raschid JF Rafeally) [#7339](https://github.com/parse-community/parse-server/pull/7339)
- Fix error when a not yet inserted job is updated (Antonio Davi Macedo Coelho de Castro) [#7196](https://github.com/parse-community/parse-server/pull/7196)
- request.context for afterFind triggers (dblythy) [#7078](https://github.com/parse-community/parse-server/pull/7078)
- Winston Logger interpolating stdout to console (dplewis) [#7114](https://github.com/parse-community/parse-server/pull/7114)
- Added convenience method `Parse.Cloud.sendEmail(...)` to send email via email adapter in Cloud Code (dblythy) [#7089](https://github.com/parse-community/parse-server/pull/7089)
- LiveQuery support for $and, $nor, $containedBy, $geoWithin, $geoIntersects queries (dplewis) [#7113](https://github.com/parse-community/parse-server/pull/7113)
- Added `requireAnyUserRoles` and `requireAllUserRoles` for Parse Cloud validator (dblythy) [#7097](https://github.com/parse-community/parse-server/pull/7097)
- Support Facebook Limited Login (miguel-s) [#7219](https://github.com/parse-community/parse-server/pull/7219)
- Removed Stage name check on aggregate pipelines (BRETT71) [#7237](https://github.com/parse-community/parse-server/pull/7237)
- Retry transactions on MongoDB when it fails due to transient error (Antonio Davi Macedo Coelho de Castro) [#7187](https://github.com/parse-community/parse-server/pull/7187)
- Bump tests to use Mongo 4.4.4 (Antonio Davi Macedo Coelho de Castro) [#7184](https://github.com/parse-community/parse-server/pull/7184)
- Added new account lockout policy option `accountLockout.unlockOnPasswordReset` to automatically unlock account on password reset (Manuel Trezza) [#7146](https://github.com/parse-community/parse-server/pull/7146)
- Test Parse Server continuously against all recent MongoDB versions that have not reached their end-of-life support date, added MongoDB compatibility table to Parse Server docs (Manuel Trezza) [#7161](https://github.com/parse-community/parse-server/pull/7161)
- Test Parse Server continuously against all recent Node.js versions that have not reached their end-of-life support date, added Node.js compatibility table to Parse Server docs (Manuel Trezza) [7161](https://github.com/parse-community/parse-server/pull/7177)
- Throw error on invalid Cloud Function validation configuration (dblythy) [#7154](https://github.com/parse-community/parse-server/pull/7154)
- Allow Cloud Validator `options` to be async (dblythy) [#7155](https://github.com/parse-community/parse-server/pull/7155)
- Optimize queries on classes with pointer permissions (Pedro Diaz) [#7061](https://github.com/parse-community/parse-server/pull/7061)
- Test Parse Server continuously against all relevant Postgres versions (minor versions), added Postgres compatibility table to Parse Server docs (Corey Baker) [#7176](https://github.com/parse-community/parse-server/pull/7176)
- Randomize test suite (Diamond Lewis) [#7265](https://github.com/parse-community/parse-server/pull/7265)
- LDAP: Properly unbind client on group search error (Diamond Lewis) [#7265](https://github.com/parse-community/parse-server/pull/7265)
- Improve data consistency in Push and Job Status update (Diamond Lewis) [#7267](https://github.com/parse-community/parse-server/pull/7267)
- Excluding keys that have trailing edges.node when performing GraphQL resolver (Chris Bland) [#7273](https://github.com/parse-community/parse-server/pull/7273)
- Use Node.js 15.13.0 in CI (Olle Jonsson) [#7312](https://github.com/parse-community/parse-server/pull/7312)
- Fix file upload issue for S3 compatible storage (Linode, DigitalOcean) by avoiding empty tags property when creating a file (Ali Oguzhan Yildiz) [#7300](https://github.com/parse-community/parse-server/pull/7300)
- Add building Docker image as CI check (Manuel Trezza) [#7332](https://github.com/parse-community/parse-server/pull/7332)
- Add NPM package-lock version check to CI (Manuel Trezza) [#7333](https://github.com/parse-community/parse-server/pull/7333)
- Fix incorrect LiveQuery events triggered for multiple subscriptions on the same class with different events [#7341](https://github.com/parse-community/parse-server/pull/7341)
- Fix select and excludeKey queries to properly accept JSON string arrays. Also allow nested fields in exclude (Corey Baker) [#7242](https://github.com/parse-community/parse-server/pull/7242)
- Fix LiveQuery server crash when using $all query operator on a missing object key (Jason Posthuma) [#7421](https://github.com/parse-community/parse-server/pull/7421)
- Add ability to pass context of an object via a header, X-Parse-Cloud-Context, for Cloud Code triggers. The header addition allows client SDK's to add context without injecting _context in the body of JSON objects (Corey Baker) [#7437](https://github.com/parse-community/parse-server/pull/7437)
- Add CI check to add changelog entry (Manuel Trezza) [#7512](https://github.com/parse-community/parse-server/pull/7512)
- Refactor: uniform issue templates across repos (Manuel Trezza) [#7528](https://github.com/parse-community/parse-server/pull/7528)
- ci: bump ci environment (Manuel Trezza) [#7539](https://github.com/parse-community/parse-server/pull/7539)
- CI now pushes docker images to Docker Hub (Corey Baker) [#7548](https://github.com/parse-community/parse-server/pull/7548)
- Allow afterFind and afterLiveQueryEvent to set unsaved pointers and keys (dblythy) [#7310](https://github.com/parse-community/parse-server/pull/7310)
- Allow setting descending sort to full text queries (dblythy) [#7496](https://github.com/parse-community/parse-server/pull/7496)
- Allow cloud string for ES modules (Daniel Blyth) [#7560](https://github.com/parse-community/parse-server/pull/7560)
- docs: Introduce deprecation ID for reference in comments and online search (Manuel Trezza) [#7562](https://github.com/parse-community/parse-server/pull/7562)
- refactor: deprecate `Parse.Cloud.httpRequest`; it is recommended to use a HTTP library instead. (Daniel Blyth) [#7595](https://github.com/parse-community/parse-server/pull/7595)
* security bump minimist from 1.2.5 to 1.2.6 ([#7884](https://github.com/parse-community/parse-server/issues/7884)) ([c5cf282](https://github.com/parse-community/parse-server/commit/c5cf282d11ffdc023764f8e7539a2bd6bc246fe1))
* sensitive keyword detection may produce false positives ([#7881](https://github.com/parse-community/parse-server/issues/7881)) ([0d6f9e9](https://github.com/parse-community/parse-server/commit/0d6f9e951d9e186e95e96d8869066ce7022bad02))
* improved LiveQuery error logging with additional information ([#7837](https://github.com/parse-community/parse-server/issues/7837)) ([443a509](https://github.com/parse-community/parse-server/commit/443a5099059538d379fe491793a5871fcbb4f377))
* adding or modifying a nested property requires addField permissions ([#7679](https://github.com/parse-community/parse-server/issues/7679)) ([6a6248b](https://github.com/parse-community/parse-server/commit/6a6248b6cb2e732d17131e18e659943b894ed2f1))
* bump nanoid from 3.1.25 to 3.2.0 ([#7781](https://github.com/parse-community/parse-server/issues/7781)) ([f5f63bf](https://github.com/parse-community/parse-server/commit/f5f63bfc64d3481ed944ceb5e9f50b33dccd1ce9))
* bump node-fetch from 2.6.1 to 3.1.1 ([#7782](https://github.com/parse-community/parse-server/issues/7782)) ([9082351](https://github.com/parse-community/parse-server/commit/90823514113a1a085ebc818f7109b3fd7591346f))
* node engine compatibility did not include node 16 ([#7739](https://github.com/parse-community/parse-server/issues/7739)) ([ea7c014](https://github.com/parse-community/parse-server/commit/ea7c01400f992a1263543706fe49b6174758a2d6))
* node engine range has no upper limit to exclude incompatible node versions ([#7692](https://github.com/parse-community/parse-server/issues/7692)) ([573558d](https://github.com/parse-community/parse-server/commit/573558d3adcbcc6222c92003829867e1a73eef94))
* package.json & package-lock.json to reduce vulnerabilities ([#7823](https://github.com/parse-community/parse-server/issues/7823)) ([5ca2288](https://github.com/parse-community/parse-server/commit/5ca228882332b65f3ac05407e6e4da1ee3ef3749))
* schema cache not cleared in some cases ([#7678](https://github.com/parse-community/parse-server/issues/7678)) ([5af6e5d](https://github.com/parse-community/parse-server/commit/5af6e5dfaa129b1a350afcba4fb381b21c4cc35d))
* security upgrade follow-redirects from 1.14.6 to 1.14.7 ([#7769](https://github.com/parse-community/parse-server/issues/7769)) ([8f5a861](https://github.com/parse-community/parse-server/commit/8f5a8618cfa7ed9a2a239a095abffa8f3fd8d31a))
* security upgrade follow-redirects from 1.14.7 to 1.14.8 ([#7801](https://github.com/parse-community/parse-server/issues/7801)) ([70088a9](https://github.com/parse-community/parse-server/commit/70088a95a78393da2a4ac68be81e63107747626a))
* server crash using GraphQL due to missing @apollo/client peer dependency ([#7787](https://github.com/parse-community/parse-server/issues/7787)) ([08089d6](https://github.com/parse-community/parse-server/commit/08089d6fcbb215412448ce7d92b21b9fe6c929f2))
* unable to use objectId size higher than 19 on GraphQL API ([#7627](https://github.com/parse-community/parse-server/issues/7627)) ([ed86c80](https://github.com/parse-community/parse-server/commit/ed86c807721cc52a1a5a9dea0b768717eec269ed))
* upgrade mime from 2.5.2 to 3.0.0 ([#7725](https://github.com/parse-community/parse-server/issues/7725)) ([f5ef98b](https://github.com/parse-community/parse-server/commit/f5ef98bde32083403c0e30a12162fcc1e52cac37))
* upgrade parse from 3.3.1 to 3.4.0 ([#7723](https://github.com/parse-community/parse-server/issues/7723)) ([d4c1f47](https://github.com/parse-community/parse-server/commit/d4c1f473073764cb0570c633fc4a30669c2ce889))
* upgrade winston from 3.5.0 to 3.5.1 ([#7820](https://github.com/parse-community/parse-server/issues/7820)) ([4af253d](https://github.com/parse-community/parse-server/commit/4af253d1f8654a6f57b5137ad310cdacadc922cc))
### Features
* add Cloud Code context to `ParseObject.fetch` ([#7779](https://github.com/parse-community/parse-server/issues/7779)) ([315290d](https://github.com/parse-community/parse-server/commit/315290d16110110938f80a6b779cc2d1db58c552))
* add Idempotency to Postgres ([#7750](https://github.com/parse-community/parse-server/issues/7750)) ([0c3feaa](https://github.com/parse-community/parse-server/commit/0c3feaaa1751964c0db89f25674935c3354b1538))
* add support for Node 16 ([#7707](https://github.com/parse-community/parse-server/issues/7707)) ([45cc58c](https://github.com/parse-community/parse-server/commit/45cc58c7e5e640a46c5d508019a3aa81242964b1))
* bump required node engine to >=12.22.10 ([#7846](https://github.com/parse-community/parse-server/issues/7846)) ([5ace99d](https://github.com/parse-community/parse-server/commit/5ace99d542a11e422af46d9fd6b1d3d2513b34cf))
* support `postgresql` protocol in database URI ([#7757](https://github.com/parse-community/parse-server/issues/7757)) ([caf4a23](https://github.com/parse-community/parse-server/commit/caf4a2341f554b28e3918c53e7e897a3ca47bf8b))
* support relativeTime query constraint on Postgres ([#7747](https://github.com/parse-community/parse-server/issues/7747)) ([16b1b2a](https://github.com/parse-community/parse-server/commit/16b1b2a19714535ca805f2dbb3b561d8f6a519a7))
* upgrade to MongoDB Node.js driver 4.x for MongoDB 5.0 support ([#7794](https://github.com/parse-community/parse-server/issues/7794)) ([f88aa2a](https://github.com/parse-community/parse-server/commit/f88aa2a62a533e5344d1c13dd38c5a0b283a480a))
### Reverts
* refactor: allow ES import for cloud string if package type is module ([b64640c](https://github.com/parse-community/parse-server/commit/b64640c5705f733798783e68d216e957044ef23c))
* update node engine to 2.22.0 ([#7827](https://github.com/parse-community/parse-server/issues/7827)) ([f235412](https://github.com/parse-community/parse-server/commit/f235412c1b6c2b173b7531f285429ea7214b56a2))
### BREAKING CHANGES
* This requires Node.js version >=12.22.10. ([5ace99d](5ace99d))
* The MongoDB GridStore adapter has been removed. By default, Parse Server already uses GridFS, so if you do not manually use the GridStore adapter, you can ignore this change. ([f88aa2a](f88aa2a))
* Removes official Node 15 support which has reached it end-of-life date. ([45cc58c](45cc58c))
* security upgrade follow-redirects from 1.14.7 to 1.14.8 ([#7802](https://github.com/parse-community/parse-server/issues/7802)) ([7029b27](https://github.com/parse-community/parse-server/commit/7029b274ca87bc8058617f29865d683dc3b351a1))
* security upgrade follow-redirects from 1.14.2 to 1.14.7 ([#7772](https://github.com/parse-community/parse-server/issues/7772)) ([4bd34b1](https://github.com/parse-community/parse-server/commit/4bd34b189bc9f5aa2e70b7e7c1a456e91b6de773))
* schema cache not cleared in some cases ([#7771](https://github.com/parse-community/parse-server/issues/7771)) ([3b92fa1](https://github.com/parse-community/parse-server/commit/3b92fa1ca9e8889127a32eba913d68309397ca2c))
* unable to use objectId size higher than 19 on GraphQL API ([#7722](https://github.com/parse-community/parse-server/issues/7722)) ([8ee0445](https://github.com/parse-community/parse-server/commit/8ee0445c0aeeb88dff2559b46ade408071d22143))
* node engine range has no upper limit to exclude incompatible node versions ([#7693](https://github.com/parse-community/parse-server/issues/7693)) ([6a54dac](https://github.com/parse-community/parse-server/commit/6a54dac24d9fb63a44f311b8d414f4aa64140f32))
* refactor: allow ES import for cloud string if package type is module ([#7691](https://github.com/parse-community/parse-server/issues/7691)) ([200d4ba](https://github.com/parse-community/parse-server/commit/200d4ba9a527016a65668738c7728696f443bd53))
- Improved schema caching through database real-time hooks. Reduces DB queries, decreases Parse Query execution time and fixes a potential schema memory leak. If multiple Parse Server instances connect to the same DB (for example behind a load balancer), set the [Parse Server Option](https://parseplatform.org/parse-server/api/master/ParseServerOptions.html) `databaseOptions.enableSchemaHooks: true` to enable this feature and keep the schema in sync across all instances. Failing to do so will cause a schema change to not propagate to other instances and re-syncing will only happen when these instances restart. The options `enableSingleSchemaCache` and `schemaCacheTTL` have been removed. To use this feature with MongoDB, a replica set cluster with [change stream](https://docs.mongodb.com/manual/changeStreams/#availability) support is required. (Diamond Lewis, SebC) [#7214](https://github.com/parse-community/parse-server/issues/7214)
- Added file upload restriction. File upload is now only allowed for authenticated users by default for improved security. To allow file upload also for Anonymous Users or Public, set the `fileUpload` parameter in the [Parse Server Options](https://parseplatform.org/parse-server/api/master/ParseServerOptions.html) (dblythy, Manuel Trezza) [#7071](https://github.com/parse-community/parse-server/pull/7071)
- Removed [parse-server-simple-mailgun-adapter](https://github.com/parse-community/parse-server-simple-mailgun-adapter) dependency; to continue using the adapter it has to be explicitly installed (Manuel Trezza) [#7321](https://github.com/parse-community/parse-server/pull/7321)
- Remove support for MongoDB 3.6 which has reached its End-of-Life date and PostgreSQL 10 (Manuel Trezza) [#7315](https://github.com/parse-community/parse-server/pull/7315)
- Remove support for Node 10 which has reached its End-of-Life date (Manuel Trezza) [#7314](https://github.com/parse-community/parse-server/pull/7314)
- Remove S3 Files Adapter from Parse Server, instead install separately as `@parse/s3-files-adapter` (Manuel Trezza) [#7324](https://github.com/parse-community/parse-server/pull/7324)
- Remove Session field `restricted`; the field was a code artifact from a feature that never existed in Open Source Parse Server; if you have been using this field for custom purposes, consider that for new Parse Server installations the field does not exist anymore in the schema, and for existing installations the field default value `false` will not be set anymore when creating a new session (Manuel Trezza) [#7543](https://github.com/parse-community/parse-server/pull/7543)
- ci: add node engine version check (Manuel Trezza) [#7574](https://github.com/parse-community/parse-server/pull/7574)
- To delete a field via the GraphQL API, the field value has to be set to `null`. Previously, setting a field value to `null` would save a null value in the database, which was not according to the [GraphQL specs](https://spec.graphql.org/June2018/#sec-Null-Value). To delete a file field use `file: null`, the previous way of using `file: { file: null }` has become obsolete. ([626fad2](626fad2))
### Notable Changes
- Alphabetical ordered GraphQL API, improved GraphQL Schema cache system and fix GraphQL input reassign issue (Moumouls) [#7344](https://github.com/parse-community/parse-server/issues/7344)
- Added Parse Server Security Check to report weak security settings (Manuel Trezza, dblythy) [#7247](https://github.com/parse-community/parse-server/issues/7247)
- EXPERIMENTAL: Added new page router with placeholder rendering and localization of custom and feature pages such as password reset and email verification (Manuel Trezza) [#7128](https://github.com/parse-community/parse-server/pull/7128)
- EXPERIMENTAL: Added custom routes to easily customize flows for password reset, email verification or build entirely new flows (Manuel Trezza) [#7231](https://github.com/parse-community/parse-server/pull/7231)
- Added Deprecation Policy to govern the introduction of breaking changes in a phased pattern that is more predictable for developers (Manuel Trezza) [#7199](https://github.com/parse-community/parse-server/pull/7199)
- Add REST API endpoint `/loginAs` to create session of any user with master key; allows to impersonate another user. (GormanFletcher) [#7406](https://github.com/parse-community/parse-server/pull/7406)
- Add official support for MongoDB 5.0 (Manuel Trezza) [#7469](https://github.com/parse-community/parse-server/pull/7469)
- Added Parse Server Configuration `enforcePrivateUsers`, which will remove public access by default on new Parse.Users (dblythy) [#7319](https://github.com/parse-community/parse-server/pull/7319)
* add support for Postgres 14 ([#7644](https://github.com/parse-community/parse-server/issues/7644)) ([090350a](https://github.com/parse-community/parse-server/commit/090350a7a0fac945394ca1cb24b290316ef06aa7))
* add user-defined schema and migrations ([#7418](https://github.com/parse-community/parse-server/issues/7418)) ([25d5c30](https://github.com/parse-community/parse-server/commit/25d5c30be2111be332eb779eb0697774a17da7af))
* setting a field to null does not delete it via GraphQL API ([#7649](https://github.com/parse-community/parse-server/issues/7649)) ([626fad2](https://github.com/parse-community/parse-server/commit/626fad2e71017dcc62196c487de5f908fa43000b))
- Support native mongodb syntax in aggregation pipelines (Raschid JF Rafeally) [#7339](https://github.com/parse-community/parse-server/pull/7339)
- Fix error when a not yet inserted job is updated (Antonio Davi Macedo Coelho de Castro) [#7196](https://github.com/parse-community/parse-server/pull/7196)
- request.context for afterFind triggers (dblythy) [#7078](https://github.com/parse-community/parse-server/pull/7078)
- Winston Logger interpolating stdout to console (dplewis) [#7114](https://github.com/parse-community/parse-server/pull/7114)
- Added convenience method `Parse.Cloud.sendEmail(...)` to send email via email adapter in Cloud Code (dblythy) [#7089](https://github.com/parse-community/parse-server/pull/7089)
- LiveQuery support for $and, $nor, $containedBy, $geoWithin, $geoIntersects queries (dplewis) [#7113](https://github.com/parse-community/parse-server/pull/7113)
- Added `requireAnyUserRoles` and `requireAllUserRoles` for Parse Cloud validator (dblythy) [#7097](https://github.com/parse-community/parse-server/pull/7097)
- Support Facebook Limited Login (miguel-s) [#7219](https://github.com/parse-community/parse-server/pull/7219)
- Removed Stage name check on aggregate pipelines (BRETT71) [#7237](https://github.com/parse-community/parse-server/pull/7237)
- Retry transactions on MongoDB when it fails due to transient error (Antonio Davi Macedo Coelho de Castro) [#7187](https://github.com/parse-community/parse-server/pull/7187)
- Bump tests to use Mongo 4.4.4 (Antonio Davi Macedo Coelho de Castro) [#7184](https://github.com/parse-community/parse-server/pull/7184)
- Added new account lockout policy option `accountLockout.unlockOnPasswordReset` to automatically unlock account on password reset (Manuel Trezza) [#7146](https://github.com/parse-community/parse-server/pull/7146)
- Test Parse Server continuously against all recent MongoDB versions that have not reached their end-of-life support date, added MongoDB compatibility table to Parse Server docs (Manuel Trezza) [#7161](https://github.com/parse-community/parse-server/pull/7161)
- Test Parse Server continuously against all recent Node.js versions that have not reached their end-of-life support date, added Node.js compatibility table to Parse Server docs (Manuel Trezza) [7161](https://github.com/parse-community/parse-server/pull/7177)
- Throw error on invalid Cloud Function validation configuration (dblythy) [#7154](https://github.com/parse-community/parse-server/pull/7154)
- Allow Cloud Validator `options` to be async (dblythy) [#7155](https://github.com/parse-community/parse-server/pull/7155)
- Optimize queries on classes with pointer permissions (Pedro Diaz) [#7061](https://github.com/parse-community/parse-server/pull/7061)
- Test Parse Server continuously against all relevant Postgres versions (minor versions), added Postgres compatibility table to Parse Server docs (Corey Baker) [#7176](https://github.com/parse-community/parse-server/pull/7176)
- Randomize test suite (Diamond Lewis) [#7265](https://github.com/parse-community/parse-server/pull/7265)
- LDAP: Properly unbind client on group search error (Diamond Lewis) [#7265](https://github.com/parse-community/parse-server/pull/7265)
- Improve data consistency in Push and Job Status update (Diamond Lewis) [#7267](https://github.com/parse-community/parse-server/pull/7267)
- Excluding keys that have trailing edges.node when performing GraphQL resolver (Chris Bland) [#7273](https://github.com/parse-community/parse-server/pull/7273)
- Use Node.js 15.13.0 in CI (Olle Jonsson) [#7312](https://github.com/parse-community/parse-server/pull/7312)
- Fix file upload issue for S3 compatible storage (Linode, DigitalOcean) by avoiding empty tags property when creating a file (Ali Oguzhan Yildiz) [#7300](https://github.com/parse-community/parse-server/pull/7300)
- Add building Docker image as CI check (Manuel Trezza) [#7332](https://github.com/parse-community/parse-server/pull/7332)
- Add NPM package-lock version check to CI (Manuel Trezza) [#7333](https://github.com/parse-community/parse-server/pull/7333)
- Fix incorrect LiveQuery events triggered for multiple subscriptions on the same class with different events [#7341](https://github.com/parse-community/parse-server/pull/7341)
- Fix select and excludeKey queries to properly accept JSON string arrays. Also allow nested fields in exclude (Corey Baker) [#7242](https://github.com/parse-community/parse-server/pull/7242)
- Fix LiveQuery server crash when using $all query operator on a missing object key (Jason Posthuma) [#7421](https://github.com/parse-community/parse-server/pull/7421)
- Add ability to pass context of an object via a header, X-Parse-Cloud-Context, for Cloud Code triggers. The header addition allows client SDK's to add context without injecting _context in the body of JSON objects (Corey Baker) [#7437](https://github.com/parse-community/parse-server/pull/7437)
- Add CI check to add changelog entry (Manuel Trezza) [#7512](https://github.com/parse-community/parse-server/pull/7512)
- Refactor: uniform issue templates across repos (Manuel Trezza) [#7528](https://github.com/parse-community/parse-server/pull/7528)
- ci: bump ci environment (Manuel Trezza) [#7539](https://github.com/parse-community/parse-server/pull/7539)
- CI now pushes docker images to Docker Hub (Corey Baker) [#7548](https://github.com/parse-community/parse-server/pull/7548)
- Allow afterFind and afterLiveQueryEvent to set unsaved pointers and keys (dblythy) [#7310](https://github.com/parse-community/parse-server/pull/7310)
- Allow setting descending sort to full text queries (dblythy) [#7496](https://github.com/parse-community/parse-server/pull/7496)
- Allow cloud string for ES modules (Daniel Blyth) [#7560](https://github.com/parse-community/parse-server/pull/7560)
- docs: Introduce deprecation ID for reference in comments and online search (Manuel Trezza) [#7562](https://github.com/parse-community/parse-server/pull/7562)
- refactor: deprecate `Parse.Cloud.httpRequest`; it is recommended to use a HTTP library instead. (Daniel Blyth) [#7595](https://github.com/parse-community/parse-server/pull/7595)
console.log(`\nThere are ${higherVersions.length} dependencies that require a higher node engine version than the parent package (${parentVersion.nodeVersion}):`);
"test:mongodb":"npm run test:mongodb:runnerstart --dbversion=$npm_config_dbversion && npm run test:mongodb:testonly --dbversion=$npm_config_dbversion",
"test:mongodb:4.0.27":"npm run test:mongodb --dbversion=4.0.27",
"test:mongodb:4.2.17":"npm run test:mongodb --dbversion=4.2.17",
"test:mongodb:4.4.10":"npm run test:mongodb --dbversion=4.4.10",
"test:mongodb:5.0.5":"npm run test:mongodb --dbversion=5.0.5",
`DeprecationWarning: The Parse Server option '${deprecations[0].optionKey}' default will change to '${deprecations[0].changeNewDefault}' in a future version.`
);
});
it('does not log deprecation for new default if option is set manually',async()=>{
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.