Mapping configuration concept

[de-jcup]

Usecase

As an administrator I want to change my ScanConfig by a rest call at administration domain. All running instances of sechub shall be synched and use this configuration

Situation

With #127 we introduced a way to configure scan behavours. This was done by @Value injection. This is okay as first attempt, but we need to restart server to have changes.

Also we got restrictions about configuration sizes (e.g. on Linux 128KB, see https://unix.stackexchange.com/questions/336934/raise-128kib-limit-on-environment-variables-in-linux )

Wanted solution

• There should be a database entry containing the config as json.
• The config shall be changeable by rest call (Usecase
• The server will validate config and denies invalid ones by HTTP code NOT ACCEPTABLE
• Because having no cluster wide events (at the moment) we do not use events, but a scheduler mechanism (or caching db based ?) to synchronize changes - using the version field from db entity should be enough to handle synch.
• changes on scan config should inform admins

[de-jcup]

With a look at #2 we must handle this carefully and consider configuration in big picture.

When having a web UI (#11 ) we need REST operations able to to handle actions like in next mockup:

Because we create an own backend application for #11 we are not forced to handle each operation as necessary for mock ui - but it's okay to make REST calls not too different/difficult...

Domain: Administration

• SUPER_ADMIN must be able to configure by REST
• https://sechubserver/api/admin/config/mapping/$mappingId/ (PUT/GET:JSON) so we hide the adapter part here - mapping could be something not only for adapters.
• JSON contains a list containing pattern,replacement,comment entries - with a look at the UI: JSON contains full table content (so we got ordering, delete automatically/implicit )
• store in adapter configuration mapping entity/table (NEW)
• for later adapter common configuration we use another table!
• identifier for all these tables will be adapterID

Domain: Scan

• can be kept as is (at least at the moment)
• must store config inside database
• initial config must be challenged - is this really the way to go? Do we need this after this issue? maybe we cut the initial part
• config service must fetch data from DB and cache it some time
• must provide event message handler (receive)
  • ADAPTER_CONFIG_CHANGED
  • SCANCONFIG_RECALCULATION

Shared kernel:

• identifier for scan config entries must be shared
• also which product supports which name pattern mappings!
• UC_ADMIN_CONFIGURES_MAPPING

[de-jcup]

Developer admin UI

To provide this as simple as possible inside developer admin UI, we will provide

• CSV Import (3 columns) -> will be transfered to json
• CSV Export (3 columns) -> JSON to CSV
• 2 Actions, shall be "Adapter->export/import configuration" -> combobox chooser (id)

[de-jcup]

We let administrators add also additional mappings (custom identifiers) no restrictions at the moment. A delete will also not be implemented this time. If somebody has accidently added a new mapping it can be reset to an empty value (means empty mapping data entity).

[de-jcup]

From main menu calling "->Adapter->Checkmarx" an adapter dialog appears, where mappings for adapter can be customized at runtime: