CPS-322 - Getting issue details... STATUS

Currently there is no validation within CPS for names/ID's. Meaning that there is no restrictions to what the following can be named

  1. Dataspaces
  2. Schema-Sets
  3. Anchors
  4. CM-handles
  5. CM-Handle Properties (out of scope)

Open Issues

#Questions/Open IssuesNotesDecisions
1What kind of naming validation should be in place?

According to this ONAP Documentation it should be alphanumeric with underscores(_) VNF and PNF Modeling Requirements - Resource IDs

Alternate approach, exclude characters:

! “” SPACE # $ % & ‘ ( ) * + , . / \ : ; < = > ? @ [ ] ^ ` { | } ~

PLease note this does allow the following special characters

- (dash)

Exclude characters:

! “” SPACE # $ % & ‘ ( ) * + , . / \ : ; < = > ? @ [ ] ^ ` { | } ~

PLease note this does allow the following special characters

- (dash)
2

Should CM-Handle ID's be more strict, or carry the same amount of strictness as anchor names. Due to the fact that we create a corresponding anchor for every CM-Handle it cannot be less strict.

As part of this commit, we can modify the code so anchor creation will happen for the cm handle registration. So if it fails the validation at this point, the CM-Handle will not be registered.CM-Handle will follow same rules. when to validate is impl. detailed
3

Should validation also be applied to Get/Query API's as opposed to just creation of the functions above? 

Not recommended as this will add little value, at a high costPrefer to validate query/get input
4Should dashes be included?A lot of dummy data and tests within CPS use dashes as part of their Network Function ID's. If we decide to not use dashes, we should also change these.Yes, see above
5Implementation approach for validationWe have discussed 3 possible libraries for implementing this validation. These include java's util library, spring validator at the service level of CPS, along with using open api's 'keyword' for dealing with CM-Handle ID validation, or using apache commons validation regex library.Have decided to use basic java util package.
6The validation logic with the regex should be implemented in a separate utility class.A new common utility class should be created specifically for regex validation as part of this user story.Will implement utility class for validation

Implementation Proposals

At CPS's service layer within the the Java API:

  • Using general the Java util regex package  and libraries for String validation using plain old java code.
  • Use Spring validator at service level for java API's for CPS-Core, along with javax's constraint package.
  • Use open api's pattern keyword for parameters passed for the cm-handle id's as part of cm-handle registration.
  • Use Apache's commons regex validation library, specifically the regex validator class as part of this library.
  • Throw Data Validation Exception(BAD_REQUEST 400 Error Code) on invalid ID's.
  • If same rules apply for anchor as CM-Handle ID, throw the exception when creating the anchor (Current code will have to be refactored to accomplish this, as CM-Handle is registered before Anchor is created).
  • Or, CPS-Core will expose a new java interface to check if anchor name is valid when registering a CM-Handle.

Pros/Cons

#Implementation ApproachProsCons
1Java Util Package
  • More consistent use of code from this library across CPS
  • Easier to write individual unit tests for.
  • Can throw more specific error message if validation doesn't match.
  • More production code
2Spring/OpenApi keyword
  • Less production code
  • Inconsistent use of one validation library across code.
  • Harder to write individual unit tests for.
  • Is more used for validation at the rest layer.
3Apache Commons Validator
  • Similar to Java Util Library.
  • Slightly less production code in validating regex
  • Adding an extra dependency for slightly less production code.
  • No labels