Move password masking functionality into LoggerController.
The is a more aggresive approach to masking password string in the logs.
Cleaning the url is still in the PromiseRouter because picking it out of the log string
would be fragile.
This will cause more log messages to be scanned for password strings, and may cause a password
string to be obsfucated that is not neccesarily part of parse internals -- but i think that is
still a good thing....
see: #2755 & #2680
* Adds CloudCode handler for beforeFind
- Allows cloud code to modify a query before it is run
- Works with promises for a safer environment
- Supports modifiying the current query
- Supports issuing new queries
* Adds test for cornercase empty queries from rest
* Makes sure restOptions is always definied
* Adds jobs endpoint protected by masterKey
* Adds connection timeout for 15 minutes in jobs
* Refactors pushStatusHandler into StatusHandler
* Adds reporting of _JobStatus
* Only accept strings as messages
* Adds test for masterKey basic auth
* Adds CloudCodeRouter for cloud_code endpoint of job status, enable Jobs feature on dashboard
* xit racing test
* Make parse-server cloud code logging much to parse.com legacy. (fixes#2501)
1. More closely mimic the wording. Include the user id.
2. Truncate input and result at 1k char.
3. Use more sensible metadata that would makes sense to index. The guideline I used was: if it makes sense to filter on, put it in metadata. If it makes sense to "free text" search on, then put it in the message.
- file and console output, logging an object does not do what on might expect. For example, logging a function's "params":
```
expected:
info: Ran cloud function aFunction for user qWHLVEsbEe with:
Input: {"foo":"bar","bar":"baz"}
Result: "it worked!" functionName=aFunction, params= { foo: "bar", "bar": baz }, user=qWHLVEsbEe
what you actually get:
info: Ran cloud function aFunction for user qWHLVEsbEe with:
Input: {"foo":"bar","bar":"baz"}
Result: "it worked!" functionName=aFunction, foo=bar, bar=baz, user=qWHLVEsbEe
```
- logging highly variable metadata is pretty useless for indexing when logs are sent to a logging repository like elastic search. In that use case, you want to index stuff you expect to filter on like user, hook type.
- finally, putting the same input and result data in both the metadata and the message makes each message much larger with no additional value (that I know of anyway :).
4. Change some of the naming of functions in trigger.js to make future work easier. I was confused about why there were three logging functions in trigger and it took me awhile to get that before hooks and after hooks are logged differently. I just changed the names to make it obvious at first glance.
5. Add some try/catches to help any future futzers see syntax errors, etc instead of just hanging.
Some log examples from unit test output:
```
info: Ran cloud function loggerTest for user YUD2os1i5B with:
Input: {}
Result: {} functionName=loggerTest, user=YUD2os1i5B
info: beforeSave triggered for MyObject for user nssehQ3wtz:
Input: {}
Result: {} className=MyObject, triggerType=beforeSave, user=nssehQ3wtz
info: afterSave triggered for MyObject for user XdznQgTD0p:
Input: {"createdAt":"2016-08-19T01:11:31.249Z","updatedAt":"2016-08-19T01:11:31.249Z","objectId":"POoOOLL89U"} className=MyObject, triggerType=afterSave, user=XdznQgTD0p
error: beforeSave failed for MyObject for user 7JHqCZgnhf:
Input: {}
Error: {"code":141,"message":"uh oh!"} className=MyObject, triggerType=beforeSave, code=141, message=uh oh!, user=7JHqCZgnhf
info: Ran cloud function aFunction for user YR3nOoT3r9 with:
Input: {"foo":"bar"}
Result: "it worked!" functionName=aFunction, user=YR3nOoT3r9
error: Failed running cloud function aFunction for user Xm6NpOyuMC with:
Input: {"foo":"bar"}
Error: {"code":141,"message":"it failed!"} functionName=aFunction, code=141, message=it failed!, user=Xm6NpOyuMC
info: Ran cloud function aFunction for user CK1lvkmaLg with:
Input: {"longString":"Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus lobortis semper diam, ac euismod diam pharetra sed. Etiam eget efficitur neque. Proin nec diam mi. Sed ut purus dolor. Nulla nulla nibh, ornare vitae ornare et, scelerisque rutrum eros. Mauris venenatis tincidunt turpis a mollis. Donec gravida eget enim in luctus.\n\nSed porttitor commodo orci, ut pretium eros convallis eget. Curabitur pretium velit in odio dictum luctus. Vivamus ac tristique arcu, a semper tellus. Morbi euismod purus dapibus vestibulum sagittis. Nunc dapibus vehicula leo at scelerisque. Donec porta mauris quis nulla imperdiet consectetur. Curabitur sagittis eleifend arcu eget elementum. Aenean interdum tincidunt ornare. Pellentesque sit amet interdum tortor. Pellentesque blandit nisl eget euismod consequat. Etiam feugiat felis sit amet porta pulvinar. Lorem ipsum dolor sit amet, consectetur adipiscing elit.\n\nNulla faucibus sem ipsum, at rhoncus diam pulvinar at. Vivamus consectetur, diam... (truncated)
Result: {"longString":"Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus lobortis semper diam, ac euismod diam pharetra sed. Etiam eget efficitur neque. Proin nec diam mi. Sed ut purus dolor. Nulla nulla nibh, ornare vitae ornare et, scelerisque rutrum eros. Mauris venenatis tincidunt turpis a mollis. Donec gravida eget enim in luctus.\n\nSed porttitor commodo orci, ut pretium eros convallis eget. Curabitur pretium velit in odio dictum luctus. Vivamus ac tristique arcu, a semper tellus. Morbi euismod purus dapibus vestibulum sagittis. Nunc dapibus vehicula leo at scelerisque. Donec porta mauris quis nulla imperdiet consectetur. Curabitur sagittis eleifend arcu eget elementum. Aenean interdum tincidunt ornare. Pellentesque sit amet interdum tortor. Pellentesque blandit nisl eget euismod consequat. Etiam feugiat felis sit amet porta pulvinar. Lorem ipsum dolor sit amet, consectetur adipiscing elit.\n\nNulla faucibus sem ipsum, at rhoncus diam pulvinar at. Vivamus consectetur, diam... (truncated) functionName=aFunction, user=CK1lvkmaLg
```
* Implement PR comments:
- add back params to metadata and add back to the test
- use screaming snake case for conts
* fix typo
* Implemented syncing afterSave/afterDelete trigger calls with REST request execution flow (Issue 2489). After this change, afterSave and afterDelete triggers CAN return a promise, which needs to be resolved inside a trigger for REST request flow to continue. If trigger doesn't return a promise, request flow continues.
* Added {} to multiline if.
* Fixed bad commit.
* Fixed problem with beforeSave triggers becoming async.
* Refactor logging to provide common logger from LoggerAdapter
Move logger logic de WinstonLoggerAdapter
Further improvements in configuration
Use logger instead of getLogger
- Removes PLog module
Reverts name changes
nits
* Adds additional logging levels as requirements
* Adds tests for logging configuration
* removes flaky test
* investigate...
* further investigation
* Adds silent option to disable console output
* Restores logs with VERBOSE in tests
* Expose controller instead of adapter, reduces method requirements for adapter
* Shuffles initializations around
* Fix doc
* Load cloudCode last to make sure the logger is available
* Adds test to make sure we can load an adapter from npm module
* extract defaults
* Adds defaultMongoURI to defaults
* fix defaults values
* Proper error for PG failures
* Disable flaky test
