# | Open Issues | Notes | Decision |
---|
1 | Which option to choose from the below solutions? To resolve Jira |
---|
server | ONAP Jira |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | CPS-679 |
---|
|
| - Need for OpenAPi contract-first description of interfaces is a priority
- Likeliness to RESTConf is nice but no firm decision or requirement on this for ORAN interfaces
- OpenAPI does not support slashes in path parameters (researched and confirmed through testing)
| - In meeting 29 Sept 2021 with Kieran McCarty and Oskar Malm and CPS Team agreed on option #1 below: resourceIdentifier will become a query parameter
- This will affect all NCMP (and DMI interface) operations with a 'resourceIdentifier'
- resourceIdentifier (for now) wil be a 'compulsory' parameter (this might change when support root or queries across the network)
|
2 | For solution no.1, should fields/depth be known parameters or part of an unknown parameter-map like 'query'? To resolve Jira |
---|
server | ONAP Jira |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | CPS-678 |
---|
|
| - For Pass-trough scenarios any parameters can be supported depending the DMI implementation
- NCMP does not support any parameter just passes-it-through for passthrough use cases
- Depth and fields could become 'known' parameters for non-passthrough scenarios. but that does not affect the suggestion solution of just a map of unknown optional parameters
| - In meeting 29 Sept 2021 with Kieran McCarty and Oskar Malm and CPS Team agreed that passthrough scenarios will just support (an optional) query parameter called 'options' with key-value map of 'unknown' parameters
- NCMP wil do no validation it only acts a as a proxy for the DMI plugin
- both passthrough read and write operations can have these 'option' but ONAP DMI plugin will only use them for read use-cases
(technically they could be passed on for write operations too, this could allow any future optional field for write operation in RESTConf. Validation would be left then to the node. as is now anyway and the DMI plugin would just respond with the error (or positive) it gets from the node Additional Note 29 Sept. CPS Development team agreed to pass on any 'options' to SDN-C.
|
Description of the bug
CPS-679
Currently, NCMP does NOT support / slashes in the resource identifier as the OpenAPI definition would regard that as separate REST paths ie. a different rest endpoint
Slashes are currently not supported by open API for path params - https://github.com/OAI/OpenAPI-Specification/issues/892#issuecomment-281170254
CPS-679
Likewise OpenAPI does NOT support any list of unknown parameters. The name (key) of each parameter must be defined in the OpenApi. Currently CPS-NCMP and DMI plugin are hardcode to accept parameters 'fields' and 'depth' only. This need to be replaced with a more flexible generic solution
Currently supported
Code Block |
---|
/v1/ch/node1/data/ds/ncmp-datastore:passthrough-operational/turing-machine:turing-machine?fields=transition-function?depth=3 |
...
Code Block |
---|
/v1/ch/node1/data/ds/ncmp-datastore:passthrough-operational/turing-machine:turing-machine/transition-function?depth=5 |
Solutions
| Description | Example | Pros & Cons |
---|
1 | Change resource Identifier from a path param to a query param in the openapi.yml | resource identifier will be mandatory options will be optional. It can contain any query param with comma seperated value
Sample of url ncmp/passthorough:Operational?resourceIdentifer=turingmachine:turingmachine/xyz/abc&queryoptions={depth=6,fields=abc/x/y/c}
Sample of definiton in openapi.yaml resourceIdentifierInPath: name: resourceIdentifier in: query description: Resource identifier to get/set the resource data required: true schema: type: string | Pros we are still using open API
Cons We are changing the URL Does not have a single resource path |
2 | Keep it as path param also but we need to assume that all values after this slash belong to this resource only | /passthoroughpassthrough:Operational/{resource-identifier: .+}.
As it is single param and if you enter the value by URL encoding then you have to change spring HttpFirewall
final StrictHttpFirewall firewall = new StrictHttpFirewall();
firewall.setAllowUrlEncodedSlash(true);
https://programmer.help/blogs/spring-security-has-its-own-firewall-you-don-t-know-how-secure-your-system-is.html
| Pros
We can still use open API
Cons of this workaround
This workaround is not advised as allows remote attackers to read arbitrary files
via a .. (dot dot) sequence with combinations of (1) "/" (slash), (2) "\" (backslash), and (3) URL-encoded backslash (%5C)
characters in the URL
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0450
https://www.baeldung.com/spring-slash-character-in-url
|
3 | Create a method in the controller without using open API |
Code Block |
---|
| @RequestMapping(value = "/v1/ch/{cmHandle}/data/ds/ncmp-datastore:passthrough-running/**",
produces = {"application/json"},
consumes = {"application/json"},
method = RequestMethod.PUT)
public ResponseEntity<Object> getResourceDataPassthroughRunningForCmHandle(
@PathVariable("cmHandle") String cmHandle, HttpServletRequest resourceIdentifier
,@RequestBody DataAccessReadRequest body,
@RequestHeader(value = "accept", required = false) String accept
,@RequestParam(value = "fields", required = false) String fields
, @Min(1) @Valid @RequestParam(value = "depth", required = false) Integer depth
) {
final var modulesListAsJson = dmiService.getResourceDataPassThroughRunningForCmHandle(cmHandle,
resourceIdentifier.toString(),
accept,
fields,
depth,
body.getCmHandleProperties());
return ResponseEntity.ok(modulesListAsJson);
} |
| Pros We may need to use this approach for other methods. Does not change the url Cons Does not use open API |
...