Notification issueshttps://community.opengroup.org/osdu/platform/system/notification/-/issues2023-12-18T16:22:59Zhttps://community.opengroup.org/osdu/platform/system/notification/-/issues/56Servicebus library upgarde for Notification service2023-12-18T16:22:59ZAlok JoshiServicebus library upgarde for Notification serviceNotification service uses below package for its service bus operations.
```xml
<groupId>com.microsoft.azure</groupId>
<artifactId>azure-servicebus</artifactId>
```
This package is outdated and should be moved to `com.azure:azure-messag...Notification service uses below package for its service bus operations.
```xml
<groupId>com.microsoft.azure</groupId>
<artifactId>azure-servicebus</artifactId>
```
This package is outdated and should be moved to `com.azure:azure-messaging-servicebus` package as [recommended by MSFT](https://mvnrepository.com/artifact/com.microsoft.azure/azure-servicebus)Chad LeongChad Leonghttps://community.opengroup.org/osdu/platform/system/notification/-/issues/55HMAC Query String should be URL Encoded2023-10-30T21:09:31ZDerek HudsonHMAC Query String should be URL EncodedSimilar to [the Register Service](https://community.opengroup.org/osdu/platform/system/register/-/issues/48), when the request that the Notification Service sends to a Push endpoint can include improperly encodes the `hmac` query string ...Similar to [the Register Service](https://community.opengroup.org/osdu/platform/system/register/-/issues/48), when the request that the Notification Service sends to a Push endpoint can include improperly encodes the `hmac` query string parameter, which allows raw `=` in the `hmac` query string parameter, which in tern can cause subscription creation to fail.M22 - Release 0.25Derek HudsonDerek Hudsonhttps://community.opengroup.org/osdu/platform/system/notification/-/issues/54/api/notification/v1/push-handlers/records-changed2023-09-26T15:27:50ZShane Hutchins/api/notification/v1/push-handlers/records-changed/api/notification/v1/push-handlers/records-changed is in the openapi spec. Found it while preship testing M20 Azure.
When attempting to try to use this API I get:
{"code": 500, "reason": "Internal Server Error", "message":"An unknown er.../api/notification/v1/push-handlers/records-changed is in the openapi spec. Found it while preship testing M20 Azure.
When attempting to try to use this API I get:
{"code": 500, "reason": "Internal Server Error", "message":"An unknown error has occurred"}%
curl -X POST -H 'Authorization: Bearer TOKEN' -H 'data-partition-id: opendes' https://osdu-ship.msft-osdu-test.org/api/notification/v1/push-handlers/records-changed
This should not return a 500.https://community.opengroup.org/osdu/platform/system/notification/-/issues/53Storage Integration Test Fails in Azure2023-07-10T08:35:38ZYifan YeStorage Integration Test Fails in AzureIn azure, notification service only retrieves new subscription every 10 minutes. The integration test only waits for 1 minute right now. Therefore, the test is not able to find the subscription it created in notification and causing the ...In azure, notification service only retrieves new subscription every 10 minutes. The integration test only waits for 1 minute right now. Therefore, the test is not able to find the subscription it created in notification and causing the test to fail.M19 - Release 0.22Yifan YeYifan Yehttps://community.opengroup.org/osdu/platform/system/notification/-/issues/52Swagger API parser issue with notification openapi2023-06-07T10:57:39ZJeyakumar DevarajuluSwagger API parser issue with notification openapiWe have validated the notification service in https://apitools.dev/swagger-parser/online/ and getting the below error.
![image](/uploads/b0e821f78e849c2db6e6324fc2cd42b1/image.png)We have validated the notification service in https://apitools.dev/swagger-parser/online/ and getting the below error.
![image](/uploads/b0e821f78e849c2db6e6324fc2cd42b1/image.png)https://community.opengroup.org/osdu/platform/system/notification/-/issues/51Service build failure due to maven version2022-12-14T12:22:04ZNur SheikhService build failure due to maven versionService builds are failing due to API incompatibility which typically happens when we refer to classes compiled in a higher version of Java and we using a lower version of Java runtime
_[ERROR] Failed to execute goal org.springframework...Service builds are failing due to API incompatibility which typically happens when we refer to classes compiled in a higher version of Java and we using a lower version of Java runtime
_[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:3.0.0:build-info (build-info) on project os-schema: Execution build-info of goal org.springframework.boot:spring-boot-maven-plugin:3.0.0:build-info failed: Unable to load the mojo 'build-info' in the plugin 'org.springframework.boot:spring-boot-maven-plugin:3.0.0' due to an API incompatibility: org.codehaus.plexus.component.repository.exception.ComponentLookupException: org/springframework/boot/maven/BuildInfoMojo has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0_
This [commit](https://community.opengroup.org/osdu/platform/system/notification/-/commit/a3ab5ad717968b0f0b34ce77ca45d1dcebcc6157) fixed the issue in azure/m12-master branch in notification service. Similar fix we have to propagate in master branch for all the OSDU services where build are failing due to maven version issue.https://community.opengroup.org/osdu/platform/system/notification/-/issues/50Google Cloud dependencies in the core part.2022-11-04T11:59:24ZRiabokon Stanislav(EPAM)[GCP]Google Cloud dependencies in the core part.Need to remove GCP cloud libs from notification core:
```
<dependency>
<groupId>com.google.http-client</groupId>
<artifactId>google-http-client</artifactId>
<version>1.30.1</version>
</depende...Need to remove GCP cloud libs from notification core:
```
<dependency>
<groupId>com.google.http-client</groupId>
<artifactId>google-http-client</artifactId>
<version>1.30.1</version>
</dependency>
<dependency>
<groupId>com.google.oauth-client</groupId>
<artifactId>google-oauth-client</artifactId>
<version>1.30.1</version>
</dependency>
<dependency>
<groupId>com.google.api-client</groupId>
<artifactId>google-api-client</artifactId>
<version>1.30.2</version>
</dependency>
<dependency>
<groupId>com.google.apis</groupId>
<artifactId>google-api-services-iam</artifactId>
<version>v1-rev289-1.25.0</version>
</dependency>
<dependency>
<groupId>com.google.oauth-client</groupId>
<artifactId>google-oauth-client</artifactId>
<version>1.31.5</version>
</dependency>
```
Core Part does not have cloud-specific libs.M15 - Release 0.18Riabokon Stanislav(EPAM)[GCP]Riabokon Stanislav(EPAM)[GCP]https://community.opengroup.org/osdu/platform/system/notification/-/issues/44Unable to process notifications2022-08-19T09:58:06ZLarissa PereiraUnable to process notifications**Issue:**
Notification service is unable to process messages after M12 and fails with a NullPointerException and message "Error generating token".
Also, the integration test _should_return20XResponseCode_when_makingValidHttpsRequest_ ...**Issue:**
Notification service is unable to process messages after M12 and fails with a NullPointerException and message "Error generating token".
Also, the integration test _should_return20XResponseCode_when_makingValidHttpsRequest_ fails with a NullPointerException which is related to the above error message for all recent [master pipelines](https://community.opengroup.org/osdu/platform/system/notification/-/commits/master)
**Proposed solution:**
We need to update the provider/notification-azure/src/main/resources/application.properties in Gitlab master to be in sync with M12 changes and to match the file in branch ‘azure/m12-master’https://community.opengroup.org/osdu/platform/system/notification/-/issues/42Need for better Notification service GCP implementation "subscriber-control-...2022-08-02T13:26:57ZRostislav Dublin (EPAM)Need for better Notification service GCP implementation "subscriber-control-topic" subscriptions management approachThis issue is created on the @Rustam_Lotsmanenko comment in the MR https://community.opengroup.org/osdu/platform/system/notification/-/merge_requests/235#note_133946
The text of the comment is:
> "... we may consider discussing the log...This issue is created on the @Rustam_Lotsmanenko comment in the MR https://community.opengroup.org/osdu/platform/system/notification/-/merge_requests/235#note_133946
The text of the comment is:
> "... we may consider discussing the logic of the Notification service related to subscription configuration ...
>
> I see two problems related to the current Notification service logic related to dynamic subscriptions, first is using a [message broker as a "source of truth"](https://community.opengroup.org/osdu/platform/system/notification/-/blob/master/provider/notification-gcp/src/main/java/org/opengroup/osdu/notification/provider/gcp/pubsub/OqmSubscriberManager.java#L208), and I believe we should move it from querying message broker to querying the database where info about subscriptions created via Register service should be.
>
> The second one is a bit heavy way of handling with dynamic creation of subscriptions per each service replica, maybe later we could consider to use a bit lightweight solution like [Redis Pub/Sub](https://redis.io/docs/manual/pubsub/), where each replica can open a listener channel that can be automatically closed on shutdown and does not require additional handling."
I invite dear colleagues @andrei_dalhikh @Yauhen_Shaliou @Rustam_Lotsmanenko @Stanislav_Riabokon to the discussion.
My opinion I will share right now as a first comment to the Issue.M14 - Release 0.17Andrei Dalhikh [EPAM/GC]Andrei Dalhikh [EPAM/GC]2022-08-01https://community.opengroup.org/osdu/platform/system/notification/-/issues/41Notification tutorial document is outdated2022-06-01T21:14:01ZAn NgoNotification tutorial document is outdatedUpdate tutorial to reflect the current behaviors of notification.
"recordUpdated" flag mentioned in the limitation no longer applies.
Also update the example to include changes to the schema change and status change.Update tutorial to reflect the current behaviors of notification.
"recordUpdated" flag mentioned in the limitation no longer applies.
Also update the example to include changes to the schema change and status change.https://community.opengroup.org/osdu/platform/system/notification/-/issues/40While running the notification collection, we are getting Access denied error.2022-08-23T15:00:05ZInsha ZeeshanWhile running the notification collection, we are getting Access denied error.Collection used :
https://community.opengroup.org/osdu/platform/testing/-/blob/master/Dev/17_CICD_Setup_NotificationAPI/Postman_Collection_17_CICD_Setup_NotificationAPI_Notification_API_CI-CD_v1.0.postman_collection__2_.json
Command
cu...Collection used :
https://community.opengroup.org/osdu/platform/testing/-/blob/master/Dev/17_CICD_Setup_NotificationAPI/Postman_Collection_17_CICD_Setup_NotificationAPI_Notification_API_CI-CD_v1.0.postman_collection__2_.json
Command
curl --location --request GET 'https://osdu-ship.msft-osdu-test.org/api/notification/v1/topics' \
--header 'Content-Type: application/json' \
--header 'data-partition-id: opendes'
Below is the error
{
"status": 401,
"message": "The user is not authorized to perform this action",
"reason": "Access denied"
}
Test results :
Status code is 200 | AssertionError: expected response to have status code 200 but got 401
Status description - | AssertionError: expected response to have status reason 'OK' but got 'Unauthorizedhttps://community.opengroup.org/osdu/platform/system/notification/-/issues/37Upgrade to Log4J 2.172021-12-21T03:06:00ZDavid Diederichd.diederich@opengroup.orgUpgrade to Log4J 2.17The Apache Foundation released another Log4j2 update, version 2.17, which address a denial of service vulnerability.
This issue tracks progress to upgrade this dependency for this project.The Apache Foundation released another Log4j2 update, version 2.17, which address a denial of service vulnerability.
This issue tracks progress to upgrade this dependency for this project.https://community.opengroup.org/osdu/platform/system/notification/-/issues/36Log4J Expedient Updates and Patches2021-12-17T16:25:57ZDavid Diederichd.diederich@opengroup.orgLog4J Expedient Updates and PatchesThis issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.This issue associates MRs that were applied to this project quickly to get a patched version ready as soon as possible. The intent is to provide a reference point for later, more thoughtful, analysis.David Diederichd.diederich@opengroup.orgDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/notification/-/issues/35Logging in a new subscription manager flow in azure doesn't contain correlati...2022-03-24T14:47:10ZYauheni LesnikauLogging in a new subscription manager flow in azure doesn't contain correlation-idThe logs from the SubscriptionManager flow doesn't contains correlation-id.
Example of affected classes:
`org.opengroup.osdu.notification.provider.azure.messageBus.SubscriptionManagerImpl`
`org.opengroup.osdu.notification.provider.azu...The logs from the SubscriptionManager flow doesn't contains correlation-id.
Example of affected classes:
`org.opengroup.osdu.notification.provider.azure.messageBus.SubscriptionManagerImpl`
`org.opengroup.osdu.notification.provider.azure.messageBus.SubscriptionClientFactImpl`
`org.opengroup.osdu.notification.provider.azure.messageBus.ProcessNotification`
`org.opengroup.osdu.notification.provider.azure.messageBus.MessageHandler`Yauheni LesnikauYauheni Lesnikauhttps://community.opengroup.org/osdu/platform/system/notification/-/issues/34Issues with request scoped beans in a new subscription manager flow in azure2022-03-24T14:47:23ZYauheni LesnikauIssues with request scoped beans in a new subscription manager flow in azureThe new SubscriptionManager flow runs outside of dispatcher servlet (http flow). Because of this, when we try to use any flow which implies usage of some request scoped beans, we get an error like this:
> No thread-bound request found: ...The new SubscriptionManager flow runs outside of dispatcher servlet (http flow). Because of this, when we try to use any flow which implies usage of some request scoped beans, we get an error like this:
> No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
An example of affected beans:
`org.opengroup.osdu.core.common.http.UrlFetchServiceImpl`,
`org.opengroup.osdu.core.common.http.HttpClientHandler`,
`org.opengroup.osdu.core.common.logging.JaxRsDpsLog`Yauheni LesnikauYauheni Lesnikauhttps://community.opengroup.org/osdu/platform/system/notification/-/issues/33Need to make acl postix of the record payload configurable in azure integrati...2021-11-19T17:27:35ZYauheni LesnikauNeed to make acl postix of the record payload configurable in azure integration testsIn the integration test `org.opengroup.osdu.notification.api.TestStorageIntegration` of azure module there is the record payload, which is a String value inside a java code. This payload contains next peace of code:
```
"...In the integration test `org.opengroup.osdu.notification.api.TestStorageIntegration` of azure module there is the record payload, which is a String value inside a java code. This payload contains next peace of code:
```
" \"acl\":{\n" +
" \"viewers\":[\n" +
" \"data.test1@opendes.contoso.com\"],\n" +
" \"owners\":[\n" +
" \"data.test1@opendes.contoso.com\"]},\n" +
```
We need to make the postfix part (opendes.contoso.com) configurable here because it may differs from env to env.Yauheni LesnikauYauheni Lesnikauhttps://community.opengroup.org/osdu/platform/system/notification/-/issues/32Add CORS and configure endpoint to services (Virtual service)2021-09-28T22:43:18ZSanjeev-SLBAdd CORS and configure endpoint to services (Virtual service)The new Istio endpoint to serve requests to the service and set up CORS policy. It is necessary to have this configured for all services which have public endpoint.
**Istio Virtual Service**
Istio Virtual Service defines a set of traff...The new Istio endpoint to serve requests to the service and set up CORS policy. It is necessary to have this configured for all services which have public endpoint.
**Istio Virtual Service**
Istio Virtual Service defines a set of traffic routing rules to apply when a host is addressed. Each routing rule defines matching criteria for traffic of a specific protocol. If the traffic is matched, then it is sent to a named destination service (or subset/version of it) defined in the registry.
Why you need to create it?
Since we are going to switch from the AGIC to the Istio ingress controller, it's necessary to configure the new Ingress controller in the same way as the old one configured. For the Istio setup, it was decided to use separate files of Virtual service for each service which have a public endpoint.
**Cross-Origin Resource Sharing (CORS)**
Browsers implement CORS to allow servers to control who is allowed to make use of their resources. The control is applied when a web page in a browser makes a request to a server at a different origin (domain). The browser will first make a preflight request to the server to determine whether the full request is permitted. This preflight request does not include any authorization (for security purposes) and the response will specify the permitted HTTP verb as well as any headers that will be accepted by the server. If the web page attempts to use a method or header not on that list, the request will be blocked by the browser.
**Solution**
The Istio VirtualService object, in addition to providing a mapping between an HTTP request's host/path and a Kubernetes service, can also provide CORS responses without requiring logic in the service. This is convenient because it separates business logic from framework overhead.
The application team should create a VirtualService object YAML file to define the HTTP request mapping by declaring one or more URL paths and a destination service to handle those paths.
To properly configure the VirtualService object's CORS support, the application team should add the appropriate attributes to declare any headers that are accepted by the service, and the HTTP verbs that the service supports. Following the principle of least privilege, it is best practice to declare only the verbs and headers actually accepted by the service; only the application team can make this determination.
See the Istio [VirtualService documentation ](https://istio.io/latest/docs/reference/config/networking/virtual-service/) for more detail.
At a minimum, most OSDU services should support the three headers Authorization, Data-Partition-Id, and Correlation-Id.Sanjeev-SLBSanjeev-SLBhttps://community.opengroup.org/osdu/platform/system/notification/-/issues/31Upgrade Core Test GCP Dependency2022-02-11T21:58:33ZDavid Diederichd.diederich@opengroup.orgUpgrade Core Test GCP Dependencyhttps://community.opengroup.org/osdu/platform/system/notification/-/issues/30Upgrade Core AWS Dependency2022-02-11T21:58:37ZDavid Diederichd.diederich@opengroup.orgUpgrade Core AWS Dependencyhttps://community.opengroup.org/osdu/platform/system/notification/-/issues/29Upgrade Core IBM Dependency2022-02-11T21:58:41ZDavid Diederichd.diederich@opengroup.orgUpgrade Core IBM Dependency