Conversation
…s a uriComponent when embedding it in a url and decode it after its been parsed as a url param.
There was a problem hiding this comment.
FYI, this is potentially getting to get more complicated in the future as we need to add support for multi-segment ids. So these are valid ids in the future (not sure if in 4.2 or later):
"simple string"42["multi", "part"]["could", "have a / or ? or number in it", 22]
In MQTT and REST the latter would be encoded/referenced by: table/could/have%20a%20%2F%20or%20%3F%20or%20number%20in%20it/22
| navigate(`/o/${customer_id}/i/${compute_stack_id}/browse/${schema}/${table}/edit/${rowData[tableState.hashAttribute]}`, { | ||
| const encodedHash = encodeURIComponent(hashValue); // encode because the hashValue can contain url components | ||
|
|
||
| navigate(`/o/${customer_id}/i/${compute_stack_id}/browse/${schema}/${table}/edit/${encodedHash}`, { |
There was a problem hiding this comment.
I believe the schema and table names should also be encoded, as there are a number of allow characters that require encoding.
There was a problem hiding this comment.
Thanks, I now encode and decode those.
Currently, I get a front-end studio error telling me that only alphanumeric or underscores are allowed. Sounds like I should adjust the allowed characters as well as the message, but maybe that's a policy decision.
Is this the place to go for allowed characters in the schema name and table name? https://github.com/HarperDB/harperdb/blob/a46383d2e537e5e93c712a038e09ef19c9a77459/validation/common_validators.js#L5
If understand correctly, the regex (/^[\x20-\x2E|\x30-\x5F|\x61-\x7E]*$/) is specifying in hex 3 ranges of allowed ascii characters. Maybe I can just use that regex in studio and unpack the values into a more up-to-date and thorough client-side error message?
Another question: is there any plan to allow unicode in hash_value, schema or table names?
There was a problem hiding this comment.
the regex (/^[\x20-\x2E|\x30-\x5F|\x61-\x7E]*$/) is specifying in hex 3 ranges of allowed ascii characters. Maybe I can just use that regex in studio and unpack the values into a more up-to-date and thorough client-side error message?
Yes, that should be correct, and I think that would be appropriate for studio to use as well.
Another question: is there any plan to allow unicode in hash_value, schema or table names?
Yes, we should absolutely do this. It is kind of not very inclusive to restrict to latin characters.
Thanks for the advisory note here. Am I ok to support this before the functionality is available? |
|
Kudos, SonarCloud Quality Gate passed!
|
Yes, I think that should be fine, like you said, it should be backwards compatible since nothing should have these ids right now. |
f3b6f0e to
8d7f915
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
2 participants
The
hash_id/ primary key was getting passed unencoded into the dynamically constructed url that triggers the JSONEditor to render a record for editing. This PR encodes/decodes the value properly when embedding in and parsing it from the studio url to prevent parsing bugs.