Handling slash in object ids #379
Replies: 4 comments 5 replies
-
|
One suggestion was to expose native db codes - this isn't going to happen. |
Beta Was this translation helpful? Give feedback.
-
|
Another possibility is to allow users to encode the id some other way - maybe base64? |
Beta Was this translation helpful? Give feedback.
-
|
Can it just be a query param instead of a path param? Easy enough to add a note to the OpenAPI doc to describe why this one is non-standard. |
Beta Was this translation helpful? Give feedback.
-
|
query parameters can have slashes in them. Whatever we do we probably have to do across the board b/c its not just clobs. |
Beta Was this translation helpful? Give feedback.
-
|
to get requests routed to the right place users probably have to put something in the {clob-id} portion of the path and it can't have a slash |
Beta Was this translation helpful? Give feedback.
-
|
My thought is this: The natural representation of an object, for example (office,location), (office,timeseries name), is place in query parameters. This way we're not actually exposing the column surrogate key (I really wish SQL had a keyword for surrogate key to make it really obvious) but the API itself can still be used as some expect it. @willbreitkreutz and (Will, I don't know Randy's github handle) were discussing this at our meeting last week. I get why they want it, and I see the value in the type of ID, I just want to hide the actual database implementation from the level of the database API so it's easier to shift the rug out later. So i think an encoded ID field is a reasonable compromise; considering how common it is to use uuids to surrogate keys these days a base64 encoded value really isn't much different visually at least. And it's more a machine-to-machine detail anyways; someone manually querying data is more likely to use the natural keys and search fields. And this split makes it a little more practical to make all the clear. |
Beta Was this translation helpful? Give feedback.
-
|
This also has the added benefit of then making the Clob and Blob controllers non-divergent from the rest. And a transition period wouldn't be too hard, just attempt a base64 decode real quick (or may just a check for only has the b64url alphabet) and operate appropriately for a time. |
Beta Was this translation helpful? Give feedback.
-
|
The really controversial question (should this prove to be the solution.) Should we call that new field:
|
Beta Was this translation helpful? Give feedback.
-
|
Follow-up comment. Blob and Clob end-points can now take an optional clob-id/blob-id query-param. If that query param is found it will be used instead of the value of the path parameter. When using the clob-id query parameter the user must still provide a valid (in the sense that it doesn't contain slashes or other illegal characters) path parameter so that the request will get routed to the correct controller end-point. When the path parameter is overridden it doesn't really matter what the user puts in the path-parameter as long as there is something there. It would be a mistake to put an invalid id in both the path-parameter and the query-parameter because in that situation the request would get blocked. A hardcoded path parameter like: "NA" "ignored" "default" "none" would all be fine choices when query-parameter override is going to be used. |
Beta Was this translation helpful? Give feedback.
-
I'm going to use Clob as an example but this affects other things, not just clobs. Say you have a clob with an id of "idwith/slash".
To get that clob you'd try to issue a get request to:
http://localhost:7000/cwms-data/clobs/idwith%2Fslash?office=SPK
The clob-id is in the path portion of the url. The id is not a query parameter (like office) its a path-parameter.
Also notice that the id has been url-encoded.
Unfortunately CDA is going to return to you this 400 error:
Tomcat, by default, doesn't allow the url to include slash characters.
Stackoverflow ( https://stackoverflow.com/a/52778888/249623 ) suggests adding:
Adding that will make the id with slashes get passed thru to our CDA code!
Unfortunately we'd have to add those options to the Tomcat run config so it would affect all the servlets on that server. Its thought that blocking Slash and Backslash characters was explicitly called out by the STIG as something we must do for security. Apparently the feature is too often abused as part of other bad behavior so we can't have nice things anymore. Even if we could get those Tomcat flags set we'd also have to get proxies configured to allow it also. Basically its probably not going to happen.
I don't think this is Javalin's fault. At least not this specific error.
The point of this discussion: What to do?
Beta Was this translation helpful? Give feedback.
All reactions