baloise / corellia Goto Github PK

See PR #48

Add support for PNG, BMP and GIF when uploading documents.

E.g. by using jakartaee/rest#535

Expected Behavior

being able to construct an ErrorResponse from Java

Actual Behavior

Exception due to neither having No-ArgsConstructor nor a JSON creator annotated constructor

Steps to Reproduce the Problem

1. throw an Exception that should be reported to the consumer, e.g. a ValidationException

Expected Behavior

It'd be useful having permalinks in our OpenAPI specifcation files (v2 and v3)

https://stackoverflow.com/questions/52703804/how-to-link-to-another-endpoint-in-swagger

Actual Behavior

There are no such links.

See #23

Expected Behavior

They are the same.

Actual Behavior

OpenAPI states 0.1.0 <--> artifact / release tags 1.0.1

The project could not be analyzed because of maven build errors. Please review the error messages here. Another build will be scheduled within 24 hours. If the build is successful this issue will be closed, otherwise the error message will be updated.

_{This is an automated GitHub Issue created by Sonatype DepShield. GitHub Apps, including DepShield, can be managed from the Developer settings of the repository administrators.}

Vulnerabilities

DepShield reports that this application's usage of lodash.isequal:4.5.0 results in the following vulnerability(s):

• (CVSS 7.4) CWE-471: Modification of Assumed-Immutable Data (MAID)

Occurrences

lodash.isequal:4.5.0 is a transitive dependency introduced by the following direct dependency(s):

• api-spec-converter:2.7.32
        └─ sway:2.0.5
              └─ z-schema:3.25.1
                    └─ lodash.isequal:4.5.0

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Actual Behavior

Calling the Rest Endpoints leads to Resteasy Exceptions like this:
Caused by: org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: ch.baloise.corellia.api.entities.ErrorResponse of media type: application/octet-stream at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:110) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:187) ... 56 more

Expected Behavior

The only information missing for a company to be processed automatically without providing a UID is the legal form information.

Actual Behavior

Currently a company has to provide a UID to be found and processed by our systems.

Implementation

Add field legalForm to the company model.

The field should be validated. Either the UID or the other information incl. legalForm should be available.

The valid values for this field is the crediForm list:

Expected Behavior

This is supposed to be an optional field.

Actual Behavior

Currently it's mandatory.

Vulnerabilities

DepShield reports that this application's usage of lodash.get:4.4.2 results in the following vulnerability(s):

• (CVSS 7.4) CWE-471: Modification of Assumed-Immutable Data (MAID)
• (CVSS 6.5) [CVE-2018-3721] lodash node module before 4.17.5 suffers from a Modification of Assumed-Immutabl...

Occurrences

lodash.get:4.4.2 is a transitive dependency introduced by the following direct dependency(s):

• api-spec-converter:2.7.32
        └─ sway:2.0.5
              └─ z-schema:3.25.1
                    └─ lodash.get:4.4.2

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Vulnerabilities

DepShield reports that this application's usage of org.yaml:snakeyaml:1.24 results in the following vulnerability(s):

• (CVSS 7.5) [CVE-2017-18640] The Alias feature in SnakeYAML 1.18 allows entity expansion during a load operat...

Occurrences

org.yaml:snakeyaml:1.24 is a transitive dependency introduced by the following direct dependency(s):

• io.swagger.core.v3:swagger-jaxrs2:2.1.0
        └─ io.swagger.core.v3:swagger-integration:2.1.0
              └─ io.swagger.core.v3:swagger-core:2.1.0
                    └─ com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.10.1
                          └─ org.yaml:snakeyaml:1.24

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Expected Behavior

A release should be publicly buildable and available for this repo.

Actual Behavior

One has to build an publish locally at the moment.

Vulnerabilities

DepShield reports that this application's usage of lodash:4.17.19 results in the following vulnerability(s):

• (CVSS 7.4) [CVE-2020-8203] Prototype pollution attack when using _.zipObjectDeep in lodash <= 4.17.15.

Occurrences

lodash:4.17.19 is a transitive dependency introduced by the following direct dependency(s):

• api-spec-converter:2.7.32
        └─ google-discovery-to-swagger:2.0.0
              └─ lodash:4.17.19
        └─ lodash:4.17.19
        └─ raml-to-swagger:1.1.0
              └─ lodash:4.17.19
        └─ sway:2.0.5
              └─ json-refs:3.0.12
                    └─ graphlib:2.1.7
                          └─ lodash:4.17.19
                    └─ lodash:4.17.19
              └─ lodash:4.17.19

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

See #25

Hi @sauterl - can you tell whether this branch is still relevant? Please file a PR or delete if no longer required- thanks!

https://github.com/baloise/corellia/tree/openapi-2.0

Expected Behavior

Add a default constructor to ErrorResponse class to enable Java reflection, which is used in most REST clients.

Actual Behavior

Steps to Reproduce the Problem

Specifications

• Version:
• Platform:
• Subsystem:

We propose to add an eventId which has to be unique per event.

According to the Zalando REST API Guidelines
https://opensource.zalando.com/restful-api-guidelines/#211
We would like to follow this recommendation for ease of communication and explicit idempotency reasons.

travis-ci.org will be closed down December 31st, 2020

Announcement: https://mailchi.mp/3d439eeb1098/travis-ciorg-is-moving-to-travis-cicom
Migration guide: https://docs.travis-ci.com/user/migrate/open-source-repository-migration

Vulnerabilities

DepShield reports that this application's usage of mem:1.1.0 results in the following vulnerability(s):

• (CVSS 7.5) CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')

Occurrences

mem:1.1.0 is a transitive dependency introduced by the following direct dependency(s):

• api-spec-converter:2.7.32
        └─ swagger2openapi:2.9.4
              └─ yargs:9.0.1
                    └─ os-locale:2.1.0
                          └─ mem:1.1.0

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

We should think about using a unified naming scheme here.

The http status codes
https://www.restapitutorial.com/httpstatuscodes.html
are the main indicator for error analysis.
To make it easier to distinguish errors we want to change the ErrorCause in our ErrorResponse as follows:

So far we had 2 Causes:

• badRequest
• inputValidation

We want to change that to

• httpClientError -> Errors like wrong formatted json, or related to message body handling errors of our rest library, except validation errors
• httpClientErrorInputValidation -> It's a httpClientError but because it's a validation problem we treat this different (structured validation error messages).
• httpServerError -> Some other cause beside of messagebody handling and validation, not data related.

This means inputValidation will have httpClientErrorInputValidation as cause and badRequest will have httpClientError or httpServerError as cause.

This will reflect the http status codes 4xx to httpClientError and 5xx to httpServerError.
Before badRequest coud be 4xx or 5xxx.

Naming issue

Change INTERNE_KORRESPONDENZ to a meaningfull expression.

Expected Behavior

being able to provide lower or upper case String as enum values

Actual Behavior

Exception:
com.fasterxml.jackson.databind.exc.InvalidFormatException: Can not deserialize value of type ch.baloise.corellia.api.entities.Document$MediaType from String "application_pdf": value not one of declared Enum instance names: [IMAGE_GIF, IMAGE_BMP, APPLICATION_PDF, IMAGE_PNG, IMAGE_TIFF, IMAGE_JPEG]
at [Source: ch.basler.common.service.camel.helper.ServletByteArrayInputStream@64cbf1ac; line: 3, column: 15] (through reference chain: ch.baloise.corellia.api.entities.Document["mediaType"])

Steps to Reproduce the Problem

use lowercase MediaType string in JSON-Request

Expected Behavior

API should provide support for contract cancellations

Actual Behavior

no op available

Specifications

• Version: stays 1.0 - additional operation

Expected Behavior

API doc update required.

Currently, the Contract object has date properties, and API docs are missing time zone information in which date should be send.

1. I suggest using UTC timezone.

I suggest:

• creationDate - the day the contract was issued. ISO 8601 UTC.
• startDate - Start of contract which means start of insurance coverage. ISO 8601 UTC.
• endDate - End of contract which means end of insurance coverage. ISO 8601 UTC.

Btw, supporting hours and minutes - would make sense and make data more precise.
E.g. sending date as 2019-12-17T10:28:21Z

There are duplicate chapters; broken layouts and redundant / outdated descriptions.

Depshield will be deprecated on Monday December 12th

Please install our new product, Sonatype Lift with advanced features

We could think about making use of: https://github.com/zalando/jackson-datatype-money

http://www.apache.org/dev/apply-license.html#new

We want to be able to identify the caller clearly and simply.
Therefore we propose to add a unique caller id field on the request structure.
The unique caller id will be determined by the callee (in our case Basler).

Expected Behavior

The image format is properly described in our OpenAPI spec.

Actual Behavior

The current description is not necessarily easy to understand.

Currently language is an optional field - which is not true from a business perspective.
We will fix this in the next upcoming version by making a language mandatory.

The following field have to be added to the create contract API endpoint.

Fields

• transaction
  -- type
  -- reason
  -- effective (optional)
• contract
  -- id (was the contractId before)
  -- type
• termsOfService
  -- type
  -- year
• payment
  -- code (was the paymentCode before)
  -- recurringType
  -- dueDate (optional)
• stampTax
• product.coverables.riskLocation
• roles.role

Example JSON

{
	...
	"transaction": {
		"type": 21,
		"reason": 51,
		"effective": "2019-11-07"
	},
	"contract": {
		"id": "EXT-TEST-001",
		"type": "EXT"
	},
	"termsOfService": {
		"type": 1368,
		"year": 2019
	},
	"payment": {
		"code": 1234,
		"recurringType": 211,
		"dueDate": "2019-11-07"
	},
	"stampTaxCode": 1801,
        "products": [
                ...
                "coverables": [
                        {
                                ...
                                "riskLocation": {
                                        "street": "Gartenstrasse",
                                        "houseNumber": "95",
                                        "zipCode": "4052",
                                        "city": "Basel"
                                }
                        }
                ]
                ...
        ],
        "roles": [
                {
                        "partnerNr": "any-partner-nr"
                }
        ]
	...
}

The following field will be added to the uploadContract API endpoint:

product.coverables.riskLocationRef

This new field is an alternative to the already existing

product.coverables.riskLocation

Both fields will be optional and only one is used to attach a risk location to a contract.

release plugin does not work as expected, we have to bypass mechanism by releasing manually

Vulnerabilities

DepShield reports that this application's usage of yargs-parser:7.0.0 results in the following vulnerability(s):

• (CVSS 7.5) CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')
• (CVSS 7.5) [CVE-2020-7608] yargs-parser could be tricked into adding or modifying properties of Object.prot...

Occurrences

yargs-parser:7.0.0 is a transitive dependency introduced by the following direct dependency(s):

• api-spec-converter:2.7.32
        └─ swagger2openapi:2.9.4
              └─ yargs:9.0.1
                    └─ yargs-parser:7.0.0

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Expected Behavior

As a user / evaluator of this web API I'd like to have a couple of good samples requests / payload to easily see what to send / receive.

Actual Behavior

There are no such examples available.

Vulnerabilities

DepShield reports that this application's usage of static-eval:0.2.3 results in the following vulnerability(s):

• (CVSS 6.5) CWE-20: Improper Input Validation

Occurrences

static-eval:0.2.3 is a transitive dependency introduced by the following direct dependency(s):

• api-spec-converter:2.7.32
        └─ google-discovery-to-swagger:2.0.0
              └─ jsonpath:0.2.12
                    └─ static-eval:0.2.3

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Due to an evolvement in business requirements we would like to remove Person and Company from the Payment entity.

As by this change the Payment entity now only will consist of one field, we propose to remove the entire payment entity and to pull up the paymentCode to Contract level.

Vulnerabilities

DepShield reports that this application's usage of com.fasterxml.jackson.core:jackson-databind:2.9.9 results in the following vulnerability(s):

• (CVSS 5.9) [CVE-2019-12814] Information Exposure

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Expected Behavior

Codacy and SonarQube lead to similar results.

Actual Behavior

They have contradictory results; hence I'd like to stay with the sonarqube findings / standards for now.

Steps to Reproduce the Problem

1. Run checks in Codacy
2. Run checks in SonarCube
3. E.g. (default) constructor rules conflict.