#5957 closed enhancement (fixed)
[patch][cla] Add Safe Sub-Expressions Support for JsonPath
Reported by: | kriszyp | Owned by: | Kris Zyp |
---|---|---|---|
Priority: | high | Milestone: | 1.2 |
Component: | Dojox | Version: | 1.0 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
Currently JsonPath? syntax, permits sub-expressions that may be any valid JavaScript? expression. This greatly limits portability because environments that do have full JavaScript? capabilities can not evaluate the expression. Safe sub-expressions use a limited set of operators that can easily be implemented in using any language without requiring a JavaScript? VM. Safe sub-expressions are limited to use the following operators: =, !=, >=, <=, +, -, /, *, ?, : JsonPath? will support a safe sub-expression evaluation syntax checking, which prevents ad-hoc sub-expressions that do not adhere to this set of operators. Safe sub-expression evaluation also prevents arbitrary code execution in JsonPath?. If user supplied JsonPath? queries are executed it is highly recommended that safe sub-expressions evaluation is used to prevent arbitrary JavaScript? execution.
Attachments (1)
Change History (8)
comment:1 Changed 13 years ago by
Component: | General → Dojox |
---|---|
Owner: | changed from anonymous to Adam Peller |
comment:2 Changed 13 years ago by
Owner: | changed from Adam Peller to Dustin Machi |
---|
Changed 13 years ago by
Attachment: | jsonPath.diff added |
---|
comment:3 Changed 13 years ago by
Milestone: | 1.1 → 1.2 |
---|---|
Summary: | Add Safe Sub-Expressions Support for JsonPath → [patch][cla] Add Safe Sub-Expressions Support for JsonPath |
comment:4 Changed 13 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Dustin Machi to kriszyp |
comment:5 Changed 13 years ago by
I have done numerous other improvements such as: New features:
- Lenient syntax handling. Right now a simply query user filter expression looks like:
$< 10) We could first of all remove the requirement to start with $, and just let it start with an operator ([ or .). Next, it doesn't seem necessary to require a paranthesis to enclose the expression following the ? on filter expression. We could have [email protected]<10 Then we could also imply that any direct names in a filter expression are properties of @ (the filter items): ?price<10 Finally, we don't really even need the brackets except when more query operations will follow the filter expression: ?price<10 If we had another operation, queries would have to retain the brackets: ?price<10[0:10]
- Add sorting support. The syntax is like:
firstName ascending by firstName or [\firstName, /lastName] descending by firstName, and then ascending by lastName for firstName ties A query might look like: $< 10[\rating] to find items under $10 and then sorting by rating (highest first) Multiple prioritized columns of sorting could be done like: $< 10[\rating, /author.firstName] which would sort first by rating (descending) and then ties in rating would be sorted by author's firstName in ascending order.
- Mapping/multi-property selection.
You can do mappings with syntax like: [=newValue] To create a list of authors: $.books[=author] To creates a list of authors who have a book for under $10 we could do: $< 10[={rating:rating, name:author.firstName + ' ' + author.lastName}] This will create a list of objects that have a rating property (from the book's rating), and a name property that is the concatenation of the author's first and last name.
- General result-level expressions. You can now do general result-level expressions:
$[0].rating > 3 Finds the rating for the first book and returns true or false if the rating is greater than 3.
Consequently this is going to be committed at dojox.json.query.
comment:6 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:7 Changed 11 years ago by
Owner: | changed from kriszyp to Kris Zyp |
---|
Patch