#

Open Issues

Notes Decision
1

Which option to choose from the below solutions?

To resolve  CPS-679 - Getting issue details... STATUS

  • 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  CPS-678 - Getting issue details... STATUS

  • 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

/v1/ch/node1/data/ds/ncmp-datastore:passthrough-operational/turing-machine:turing-machine?fields=transition-function?depth=3
Wanted (currently not) supported


/v1/ch/node1/data/ds/ncmp-datastore:passthrough-operational/turing-machine:turing-machine/transition-function?depth=5


Solutions

DescriptionExamplePros & Cons
1Change 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&options={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
2Keep it as path param also but we need to assume that all values after this slash belong to this resource only
/passthrough: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
3Create a method in the controller without using open API


    @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



                
        
    
        


                        
    





    

	

		
    
    
            
  • 
            No labels
        
    •