Open
Description
New Issue Checklist
- I am not disclosing a vulnerability.I am not just asking a question.I have searched through existing issues.I can reproduce the issue with the latest version of Parse Server.
Issue Description
When post an invalid iso date string, the post success instead of return 400 with error message
Steps to reproduce
curl --location --request POST 'http://localhost:1337/parse/classes/gordonTest' \
--header 'Content-Type: application/json' \
--header 'x-parse-master-key: isotest' \
--data-raw '{
"isoTest":{
"__type":"Date",
"iso":"not iso"
}
}'
Actual Outcome
The post success and result value is 1970-01-01T00:00:00.000Z
Expected Outcome
Returns 400 with message field isoTest is not a proper iso string
Environment
Server
- Parse Server version: 4.4.0
- Operating system: Mac
- Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): local
Database
- System (MongoDB or Postgres): MongoDB
- Database version: 4.2.10
- Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): MongoDB Atlas
Client
http
Logs
[39645] parse-server running on http://localhost:1337/parse
verbose: REQUEST for [POST] /parse/classes/gordonTest: {
"isoTest": {
"__type": "Date",
"iso": "not iso"
}
} {"method":"POST","url":"/parse/classes/gordonTest","headers":{"content-type":"application/json","x-parse-master-key":"isotest","user-agent":"PostmanRuntime/7.26.8","accept":"*/*","cache-control":"no-cache","postman-token":"6a0c9a67-cfd9-48d6-8c75-8a1cfa6f40b3","host":"localhost:1337","accept-encoding":"gzip, deflate, br","connection":"keep-alive","content-length":"74"},"body":{"isoTest":{"__type":"Date","iso":"not iso"}}}
verbose: RESPONSE from [POST] /parse/classes/gordonTest: {
"status": 201,
"response": {
"objectId": "K01d1kyetL",
"createdAt": "2020-12-09T21:55:59.158Z"
},
"location": "http://localhost:1337/parse/classes/gordonTest/K01d1kyetL"
} {"result":{"status":201,"response":{"objectId":"K01d1kyetL","createdAt":"2020-12-09T21:55:59.158Z"},"location":"http://localhost:1337/parse/classes/gordonTest/K01d1kyetL"}}
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Participants
Activity
mtrezza commentedon Dec 9, 2020
Thanks for reporting.
I can confirm this behavior. It could almost be considered graceful failing, because the resulting date entry for an invalid date is
1970-01-01T00:00:00.000Z. But overall I think we should consider this a trivial bug and add date string validation.Would you want to open a PR and add the validation? Something simple like
isNaNwould probably suffice.Note: If the behavior is changed to fail with error, it should be noted as a breaking change in the change log.