@@ -219,3 +219,134 @@ This test verifies the direct resource addressing logic and the error reporting.
***Step 2**: **200 OK** (Returns the specific rule object).
***Step 4**: **404 Not Found** (Ensures the resource no longer exists in the registry).
## Test Case 9: Discover Published service APIs by Unauthorised API Invoker Visibility Control
**Test ID**: `visibility_control-9`
**Description**:
This test case verifies that an **Invoker** cannot discover a published API if a visibility control rule explicitly restricts it. It tests the basic integration between the discovery service and the visibility control logic.
**Pre-Conditions**:
* The **CAPIF** services are deployed and reachable.
* A **Provider** has been registered and onboarded at **CCF**.
* A service API is published by the provider.
* An **Invoker** is registered and onboarded at **CCF**.
* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned.
**Execution Steps**:
1. Authenticate as **Invoker** and send a **GET** request to the Discovery API to ensure the published API is initially visible.
2. Authenticate as **Superadmin**.
3. Send a **POST** request to `{apiRoot}/helper/visibility-control/rules` to create a rule that hides the API for this specific **API Invoker**.
4. Authenticate as **Invoker** and send a **GET** request to the Discovery API again.
5.**Superadmin** sends a **DELETE** request for the created `ruleId`.
6.**Superadmin** sends a **GET** request to the rules list to verify it is empty.
**Expected Result**:
***Initial Discovery**: **200 OK** (The API is discovered).
***Rule Creation**: **201 Created**.
***Second Discovery**: **404 Not Found**. The response body must contain a `ProblemDetails` object with the `detail` specifying **"API Invoker {invoker_id} has no visible APIs after applying visibility rules"**.
***Rule Deletion**: **204 No Content**.
***Final List**: **200 OK** (List length is **0**).
---
## Test Case 10: Discover Published service APIs by Unauthorised API Invoker Visibility Control (two APIs)
**Test ID**: `visibility_control-10`
**Description**:
This test case validates the discovery process when a **Provider** has published multiple APIs. It verifies that applying an explicit visibility rule to **deny** access to one specific API correctly hides only that targeted API from the **Invoker**, while any other published APIs remain unaffected and fully discoverable.
**Pre-Conditions**:
* The **CAPIF** services are deployed and reachable.
* A **Provider** is registered and onboarded at **CCF**.
***Two** distinct service APIs are published by the same provider.
* An **Invoker** is registered and onboarded at **CCF**.
* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned.
**Execution Steps**:
1. Authenticate as **Invoker** and send a **GET** request to the Discovery API to ensure both APIs are initially visible.
2. Authenticate as **Superadmin**.
3. Send a **POST** request to `{apiRoot}/helper/visibility-control/rules` creating a rule that targets only **one** of the published APIs for the invoker.
4. Authenticate as **API Invoker** and send a **GET** request to the Discovery API again.
5.**Superadmin** sends a **DELETE** request for the created `ruleId`.
**Expected Result**:
***First Discovery**: **200 OK** (List length of the discovery APIs `serviceAPIDescriptions` is **2**).
***Rule Creation**: **201 Created**.
***Second Discovery**: **200 OK**. The `serviceAPIDescriptions` list length must be **1**, containing the targeted API and explicitly not containing the denied API.
***Rule Deletion**: **204 No Content**.
---
## Test Case 11: Discover Published service APIs by Unauthorised API Invoker Visibility Control (having several rules)
**Test ID**: `visibility_control-11`
**Description**:
This test validates the conflict resolution logic when multiple sequential rules apply to the same API and Invoker. Specifically, it verifies that if an initial rule denies discovery, a subsequently created rule allowing access, the system will always enforce the most recently created or updated rule.
**Pre-Conditions**:
* The **CAPIF** services are deployed and reachable.
* A **Provider** is registered and onboarded at **CCF**.
***Two** distinct service APIs are published by the same provider.
* An **Invoker** is registered and onboarded at **CCF**.
* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned.
**Execution Steps**:
1. Authenticate as **Invoker** and send a **GET** request to the Discovery API to ensure the API is visible.
2. Authenticate as **Superadmin** and create a first visibility rule (blocking discovery) for the **API Invoker**.
3.**API Invoker** sends a **GET** request to the Discovery API.
4.**Superadmin** creates a second visibility rule (allowing discovery) for the same **Invoker** and API.
5.**API Invoker** sends a **GET** request to the Discovery API again.
**Expected Result**:
***Initial Discovery**: **200 OK**.
***First Rule Creation**: **201 Created**.
***Second Discovery (Blocked)**: **404 Not Found** with `detail` specifying **"API Invoker {invoker_id} has no visible APIs after applying visibility rules"**.
***Second Rule Creation**: **201 Created**.
***Third Discovery (Allowed)**: **200 OK** (List length is **1**, containing the published API).
---
## Test Case 12: Discover Published service APIs by Unauthorised API Invoker Visibility Control (update the rule and see changes in the discovery process)
**Test ID**: `visibility_control-12`
**Description**:
This test validates the dynamic application of rule modifications. It ensures that updating a rule's `enabled` state via a **PATCH** request immediately affects the discovery process for API Invokers.
**Pre-Conditions**:
* The **CAPIF** services are deployed and reachable.
* A **Provider** is registered and onboarded at **CCF**.
***Two** distinct service APIs are published by the same provider.
* An **Invoker** is registered and onboarded at **CCF**.
* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned.
**Execution Steps**:
1. Authenticate as **Invoker** and send a **GET** request to the Discovery API to ensure the API is visible.
2. Authenticate as **Superadmin** and create a rule that hides the API.
3.**API Invoker** sends a **GET** request to the Discovery API.
4.**Superadmin** sends a **PATCH** request to `{apiRoot}/helper/visibility-control/rules/{ruleId}` changing the `enabled` field to **False**.
5.**API Invoker** sends a **GET** request to the Discovery API again.
6.**Superadmin** sends a **DELETE** request for the `ruleId`.
**Expected Result**:
***Initial Discovery**: **200 OK**.
***Rule Creation**: **201 Created**.
***Discovery (Rule Enabled)**: **404 Not Found** with `detail` specifying **"API Invoker {invoker_id} has no visible APIs after applying visibility rules"**.
***Rule Update (PATCH)**: **200 OK**.
***Discovery (Rule Disabled)**: **200 OK** (The API is discoverable again, list length is **1**).
