Skip to content
Snippets Groups Projects
Unverified Commit c683a631 authored by Jorge Echevarria Uribarri's avatar Jorge Echevarria Uribarri Committed by GitHub
Browse files

Fix minor changes (#6)


* Add OpenCAPIF 2.0 support in list of releases supported (only in doc, testing to be conducted),
* Update sdk_configuration.md
* Fix authorization typo and update sdk config doc.
* Mistakes fixed related to OpenCAPIF SDK review
* Highlighted missing variables, functions and files,
* Removed AEF Security API support from Known issues, since it is already implemented.

---------

Co-authored-by: default avatarDaniel García <daniel.garciasanchez@telefonica.com>
Co-authored-by: default avatarJorgeEcheva26 <jorge.echevarriauribarri.practicas@telefonica.es>
parent b60dbb8c
No related branches found
No related tags found
1 merge request!1Sdk v0.1 (#1)
......@@ -8,6 +8,7 @@ OpenCAPIF SDK provides a set of libraries to enable either CAPIF provider and in
Current version of OpenCAPIF SDK is compatible with following publicly available releases:
- [OpenCAPIF Release 1.0](https://ocf.etsi.org/documentation/v1.0.0-release/)
- OpenCAPIF Release 2.0
This document serves as the [main bootstrap reference](#networkapp-developer-path) to start working with OpenCAPIF SDK. For advanced users, refer to [OpenCAPIF full documentation](./doc/sdk_full_documentation.md) section to dig into all available features.
......@@ -17,15 +18,16 @@ This document serves as the [main bootstrap reference](#networkapp-developer-pat
2. [Network App developers](#network-app-developers)
3. [OpenCAPIF SDK summary](#opencapif-sdk-summary)
4. [OpenCAPIF SDK requirements](#opencapif-sdk-requirements)
5. [OpenCAPIF SDK Configuration](./doc/sdk_configuration.md)
6. [Network App developer path](#network-app-developer-path)
5. [OpenCAPIF SDK data schema](#opencapif-sdk-data-schema)
6. [OpenCAPIF SDK Configuration](./doc/sdk_configuration.md)
7. [Network App developer path](#network-app-developer-path)
1. [Provider Network App](#provider-network-app)
* [Provider Network App sample](#provider-network-app-sample)
2. [Invoker Network App](#invoker-network-app)
* [Provider Network App sample](#provider-network-app-sample)
7. [**OpenCAPIF SDK full documentation**](./doc/sdk_full_documentation.md)
8. [OpenCAPIF SDK known issues](#opencapif-sdk-known-issues)
9. [OpenCAPIF SDK developers](./doc/sdk_developers.md)
8. [**OpenCAPIF SDK full documentation**](./doc/sdk_full_documentation.md)
9. [OpenCAPIF SDK known issues](#opencapif-sdk-known-issues)
10. [OpenCAPIF SDK developers](./doc/sdk_developers.md)
# Repository structure
......@@ -46,7 +48,7 @@ This document serves as the [main bootstrap reference](#networkapp-developer-pat
- [config](./config/): contains OpenCAPIF SDK configuration files samples. These samples illustrate the structure of the configuration files ir order to use SDK properly. Go to the [configuration section](./doc/sdk_configuration.md) for more details,
- [doc](./doc/): contains documentation related files to this README,
- [installation](./installation/): this folder stores the Pyhton [requeriments.txt](./installation/requirements.txt) file that is required to complete the [SDK developers section](./doc/sdk_developers.md),
- [installation](./installation/): this folder stores the Python [requeriments.txt](./installation/requirements.txt) file that is required to complete the [SDK developers section](./doc/sdk_developers.md),
- [network_app_samples](./network_app_samples/): this folder contains both provider and invoker Network App samples explained further in this document at [network app developer path](#network-app-developer-path),
- [samples](./samples/): contains sample files related to SDK configuration, API definitions and SDK configuration via environment variables,
- [scripts](./scripts/): single scripts to individually test functionality though command line. For more information on how to use these go to the [full documentation section](./doc/sdk_full_documentation.md),
......@@ -66,13 +68,13 @@ Next image illustrates how CAPIF works and where the SDK provides means to integ
For that purpose Network Apps play 2 different roles when interacting with CAPIF:
- **Invoker**: a Network App acting as an Invoker is responsible for consuming APIs exposed by other services. This role represents an external application or service that calls the 3GPP northbound APIs to utilize the network’s functionalities.
- **Provider**: a Network App acting as a Provider is responsible for exposing its own APIs//services for use by Invokers. This role represents an entity that offers services through APIs, making them available to other external applications or Invokers.A provider also is distinguished for having three parts.
- **Provider**: a Network App acting as a Provider is responsible for exposing its own APIs/services for use by Invokers. This role represents an entity that offers services through APIs, making them available to other external applications or Invokers.A provider also is distinguished for having three parts.
- The AMF(API Management function), supplies the API provider domain with administrative capabilities. Some of these capabilities include, auditing the service API invocation logs received from the CCF, on-boarding/off-boarding new API invokers and monitoring the status of the service APIs.One provider can have only one AMF.
- The **AMF (API Management Function)**, supplies the API provider domain with administrative capabilities. Some of these capabilities include, auditing the service API invocation logs received from the CCF, on-boarding/off-boarding new API invokers and monitoring the status of the service APIs.One provider can have only one AMF.
- The APF (API Publishing Function), is responsible for the publication of the service APIs to CCF in order to enable the discovery capability to the API Invokers.One provider can have multiple APFs.
- The **APF (API Publishing Function)**, is responsible for the publication of the service APIs to CCF in order to enable the discovery capability to the API Invokers.One provider can have multiple APFs.
- AEF(API Exposing Function), is responsible for the exposure of the service APIs. Assuming that API Invokers are authorized by the CCF, AEF validates the authorization and subsequently provides the direct communication entry points to the service APIs. AEF may also authorize API invokers and record the invocations in log files.One provider can have multiple AEFs
- The **AEF (API Exposing Function)**, is responsible for the exposure of the service APIs. Assuming that API Invokers are authorized by the CCF, AEF validates the authorization and subsequently provides the direct communication entry points to the service APIs. AEF may also authorize API invokers and record the invocations in log files.One provider can have multiple AEFs
OpenCAPIF SDK brings a set of functions to integrate with the 5G Core's function CAPIF, as defined in [3GPP Technical Specification (TS) 29.222 V18.5.0 Common API Framework for 3GPP Northbound APIs](https://www.etsi.org/deliver/etsi_ts/129200_129299/129222/18.05.00_60/ts_129222v180500p.pdf). This section shows the mapping between the Python functions available in this SDK and the CAPIF OpenAPI APIs defined the reference standard:
......@@ -100,7 +102,6 @@ NOTE: Above mentioned CAPIF APIs are defined in these 3GPP references:
- [CAPIF Discover API specification](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Discover_Service_API.yaml)
- [CAPIF Publish API specification](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Publish_Service_API.yaml)
- [CAPIF Security API specification](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Security_API.yaml)
- [AEF Security API specification](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_AEF_Security_API.yaml)
NOTE: In the [3GPP Technical Specification (TS) 29.222 V18.5.0 Common API Framework for 3GPP Northbound APIs](https://www.etsi.org/deliver/etsi_ts/129200_129299/129222/18.05.00_60/ts_129222v180500p.pdf) the `service` concept is understood as equal as the `API` concept.
......@@ -108,7 +109,7 @@ NOTE: In the [3GPP Technical Specification (TS) 29.222 V18.5.0 Common API Framew
## OpenCAPIF SDK requirements
To utilize the OpenCAPIF SDK, a registered user account within the target CAPIF instance is required.
To use the OpenCAPIF SDK, a registered user account within the target CAPIF instance is required.
**Contact the administrator to obtain the required predefined credentials (CAPIF username and password).**
......@@ -163,20 +164,18 @@ Code is next explained step by step:
In this phase, the SDK creates and stores all the necessary files for using CAPIF as a provider, such as the authorization certificate, the server certificate and each of the APFs and AEFs certificates .Furthermore creates a file named `provider_capif_ids.json`, which stores important information about the provider.
3. **Prepare API details:** \
In the `provider_folder`, more specifically in the `capif_username` folder, it will be located the provider API details file.\
This file contains all the APFs and AEFs ids that have already onboarded with this `capif_username`.\
Also it is very important to have previously prepared the API description of the API is going to be published.\
This file needs to follow the [CAPIF_Publish_Service_API](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Publish_Service_API.yaml).
Choose one APF and the AEFs identifiers, and fulfill the publish_req structure and the api_description_path.
In the `provider_folder`, more specifically in the `capif_username` folder, it will be sotres the provider API details file. This file contains all the APFs and AEFs IDs that have already onboarded with this `capif_username`.
The provider_capif_ids variable is a dictionary which contains key-values of all the APFs and AEFs stored as name: ID.
It is also important to have previously prepared the **API schema description** file of the API to be published. **This file must follow the [CAPIF_Publish_Service_API](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Publish_Service_API.yaml) 3GPP specification.**
Choose one APF and the AEF identifiers, and fulfill the `publish_req` structure and the `api_description_path`.
This publish_req field can also be filled with object variables already stored at provider object.
The `provider_capif_ids` variable is a dictionary which contains key-values of all the APFs and AEFs stored as name: ID.
4. **Publish the services:** \
Use the publish_services() method to register the APIs with the CAPIF framework(don't forget to update the capif_provider_connector constructor in order to use the new APF and AEFs):
This `publish_req` field can also be filled with object variables already stored at provider object.
In this phase, the SDK does the publishing of the provided API specification.
5. **Publish the services:** \
Use the `publish_services()` method to register the APIs with the CAPIF framework. In this phase, the SDK does the publishing of the provided API specification.
**At the end of this step, the API will be available for Invokers to be consumed.**
......@@ -197,11 +196,11 @@ Within the `provider_folder`, the SDK stores the created folders named with pref
- `service_received.json`: if it is already used to get an API or get all APIs functionality, it will contain the response of last request,
- `provider_service_ids.json`: contains the currently published APIs with their `api_id`.
All the configuration values are available within the object capif_provider_connector.
All the configuration values are available within the object `capif_provider_connector`.
The provider_service_ids variable stores the `provider_service_ids.json` content in a dictionary form.
The `provider_service_ids` variable stores the `provider_service_ids.json` content in a dictionary form.
The provider_capif_ids variable stores the `provider_capif_ids.json` content in a dictionary form.
The `provider_capif_ids` variable stores the `provider_capif_ids.json` content in a dictionary form.
## Invoker Network App
......@@ -249,7 +248,7 @@ Code is next explained step by step:
Use the `get_tokens()` method to obtain the necessary tokens for authenticating API requests.
**At the end of this flow, the invoker has been onboarded and it is ready to use target APIs.** All required information, including the access_token to use the available APIs, is stored at `capif_api_security_context_details.json` file. This file is placed in the invoker_folder path, specifically in the folder that corresponds to the capif_username used in the capif_sdk_config.json. A sample of the [capif_api_security_context_details](./samples/capif_api_security_context_details_sample.json) is also available.
**At the end of this flow, the invoker has been onboarded and it is ready to use target APIs.** All required information, including the access_token to use the available APIs, is stored at `capif_api_security_context_details.json` file. This file is placed in the invoker_folder path, specifically in the folder that corresponds to the capif_username used in the `capif_sdk_config.json`. A sample of the [capif_api_security_context_details](./samples/capif_api_security_context_details_sample.json) is also available.
Now, Invoker Network App can use access tokens to consume real services.
......@@ -263,7 +262,7 @@ Make sure that the [Provider-Network App](./network_app_samples/network_app_prov
For testing APIs availability, after running both samples([Provider-Network App](./network_app_samples/network_app_provider_sample/network_app_provider.py) and [Invoker-Network App](./network_app_samples/network_app_invoker_sample/network_app_invoker.py)) the invoker app will return the access token.
Also, in the same Invoker-Network folder is available a [Postman structure](./network_app_samples/network_app_invoker_sample/postman/).In order to test these APIs, the access token returned in the Invoker-Network App must be placed in the Postman environment, more specifically in the access_token variable.
Also, in the same Invoker-Network folder is available a [Postman structure](./network_app_samples/network_app_invoker_sample/postman/).In order to test these APIs, the access token returned in the Invoker-Network App must be set in the Postman environment, more specifically in the `access_token` variable.
Another alternative is to import the [Postman structure](./network_app_samples/network_app_invoker_sample/postman/) in your own postman account and fill the `postman_api_key` and the `environment_id` fields within the [Invoker-Network App](./network_app_samples/network_app_invoker_sample/network_app_invoker.py). Here is an example of these two fields that need to be fulfilled.
......@@ -285,9 +284,9 @@ In the `invoker_folder`, it will be located several folders with each `capif_use
2. If the Service Discovery Functionality has already been used , it will be found all the available APIs with their information,
3. If the Service Get Token functionality has already been used , it will be found the access token for using the APIs that has already been discovered.
The `token` variable is also available for retrieving the JWT token after the get_tokens() method.
The `token` variable is also available for retrieving the JWT token after the `get_tokens()` method.
The invoker_capif_details variable stores the `capif_api_security_context_details.json` content in a dictionary form.
The `invoker_capif_details` variable stores the `capif_api_security_context_details.json` content in a dictionary form.
# OpenCAPIF SDK known issues
......@@ -302,4 +301,3 @@ There are some features which **are not currently available at latest OpenCAPIF
- /trustedInvokers/{apiInvokerId}/delete (POST)
- /trustedInvokers/{apiInvokerId} (GET)
- /trustedInvokers/{apiInvokerId} (DELETE)
- [AEF_Security_API](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_AEF_Security_API.yaml)
......@@ -10,9 +10,10 @@
"invoker_folder": "",
"capif_callback_url": "",
"supported_features":"",
"check_authorization":{
"check_authentication":{
"ip":"",
"port":""
},
"cert_generation": {
"csr_common_name": "",
"csr_organizational_unit": "",
......
......@@ -7,7 +7,7 @@ Before starting the configuration process, it is required that both the [require
- [As a Network App Invoker](#network-app-invoker)
- [As a Network App Provider](#network-app-provider)
- [Descriptions of capif_sdk_config Fields](#descriptions-of-capif_sdk_config-fields)
- [Configuration via capif-sdk-register.json](#configuration-via-capif-sdk-registerjson)
- [Configuration via capif_sdk_register.json](#configuration-via-capif-sdk-registerjson)
## Configuration via `capif_sdk_config.json`
......@@ -35,9 +35,8 @@ When configuring the SDK as a **Network App Invoker**, the following fields must
- `cert_generation` (fields such as `csr_common_name`, `csr_country_name`, etc.)
**Optional:**
To enable the discovery of specific APIs, the fields under [`discover_filter`](#configuration-of-discover_filter) can be configured.
To use check_authentication() it will be required to fill up the `ip` and `port` parameters within the `check_authentication` variable.
- `discover_filter`: useful to enable the discovery of specific APIs. Some fields under [`discover_filter`](#configuration-of-discover_filter) structure required to be configured when using discovery filters. Check devoted section below,
- `check_authentication`: useful to use `check_authentication()` function to validate features from a target provider, it will be required to fill up the `ip` and `port` parameters within the `check_authentication` variable.
### Network App Provider
......@@ -54,7 +53,9 @@ For SDK configuration as a **Network App Provider**, the following fields are re
The `discover_filter` section adheres to the parameters defined in the GET request schema of the [Discover Services API](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Discover_Service_API.yaml).
To utilize the service discovery functionality, the `discover_filter` fields should be populated with the desired filters. It is important to note that fields such as `api-name` must contain only one object of each type (i.e., no lists are allowed).
To use the service discovery functionality, the `discover_filter` fields should be populated with the desired filters. **It is important to note that fields such as `api-name` must contain only one entry of each type (i.e., no lists are allowed in api-name).**
For instance if the invoker fill the `api-name` field, the `discover()` functionality will retrieve only one API, the one that matches the exact name of the `api-name`.
Before running the Invoker Service Discovery Functionality, the Invoker must be onboarded to CAPIF.
......
......@@ -25,7 +25,7 @@ The repository provides two modes for utilizing the OpenCAPIF SDK:
**IMPORTANT**: All SDK configuration files must be filled out based on the intended role and features. Further details can be found in the [Configuration Section](./sdk_configuration.md).
**NOTE**: The register file is not required for SDK usage, only for SDK consumers that wish to create their capif_username.
**NOTE**: The register file is not required for SDK usage, only for SDK consumers that wish to create their `capif_username`.
## Table of Contents
......@@ -86,28 +86,31 @@ OpenCAPIF SDK references:
The SDK streamlines API publishing with the option to select specific APFs and AEFs. A copy of the uploaded API is stored in `capif_<api_name>_<api_id>.json`, and the `provider_capif_ids.json` is updated with the API name and its ID.
### Service Deletion
**Important**: The SDK will automatically add in the `custom operations`, within the API description path, the capabilities for exposing the [AEF_security](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_AEF_Security_API.yaml) methods. The developer must code this API endpoints.
**Required SDK inputs**:
- publisher_apf_id
- publisher_aefs_ids
The SDK simplifies the process of publishing an API in CAPIF, with the option to select specific APFs and AEFs. Before publishing, ensure you’ve [onboarded as a provider](#provider-onboarding).
### Service Deletion
**Required SDK inputs**:
OpenCAPIF SDK references:
- **Function**: `unpublish_service()`
- **Script**: `provider_unpublish_api.py`
The SDK simplifies API deletion. Service deletion requires prior onboarding and service publication.
**Required SDK inputs**:
- publisher_apf_id
- publisher_aefs_ids
### Service Updates
### Service Update
OpenCAPIF SDK references:
- **Function**: `update_service()`
- **Script**: `provider_update_api.py`
This function enables the updating of a previously registered API. Selecting APFs and AEFs is possible. Onboarding and service publishing are prerequisites.
This function enables to update a previously registered API. Selecting APFs and AEFs is possible. Onboarding and service publishing are prerequisites.
**Required SDK inputs**:
- service_api_id
......@@ -120,13 +123,18 @@ OpenCAPIF SDK references:
- **Function**: `get_service()`
- **Script**: `provider_get_published_api.py`
Retrieve information on a previously published service, stored in `service_received.json`. Prior onboarding and service publication are necessary.
Retrieve information of a previously published service, stored in `service_received.json`. Prior onboarding and service publication are necessary.
**Required SDK inputs**:
- service_api_id
- publisher_apf_id
### Get All Services
OpenCAPIF SDK references:
- **Function**: `get_all_services()`
- **Script**: `provider_get_all_published_api.py`
Retrieve information about all previously published services in `service_received.json`. Ensure you are [onboarded as a provider](#provider-onboarding) and have [published services](#services-publishing).
**Required SDK input**:
......@@ -140,6 +148,9 @@ OpenCAPIF SDK references:
- **Functions**: `update_provider()` and `offboard_provider()`
- **Scripts**: `provider_capif_connector_update.py` and `provider_capif_connector_offboarding.py`
`update_provider()`: The provider updates his features such as `APFs`, `AEFs`, etc...
`offboard_provider()`: The provider offboards from CAPIF, this will cause the erase of the published APIs that were currently exposed.
The provider must be onboarded before using these features.
![Provider_update-offboard](./images/flows_provider_update_offboard.jpg)
......@@ -198,12 +209,11 @@ The SDK facilitates JWT token creation for secure access to target APIs. This pr
OpenCAPIF SDK references:
- **Function**: `check_authentication()`
The SDK allows the API invoker to confirm the `supported_features` from the API exposing function(AEF).
The SDK allows the Network App Invoker to check the `supported_features` from the target Provider's API exposing function (AEF).
It is important to have obtained the [JWT token](#obtain-jwt-tokens) previously.
It is mandatory to have obtained the [JWT token](#obtain-jwt-tokens) previously.
**Required SDK inputs**:
- check_authentication
![Invoker_check_authentication](./images/flows_invoker_check_authentication.jpg)
......@@ -211,7 +221,6 @@ It is important to have obtained the [JWT token](#obtain-jwt-tokens) previously.
### Update and Offboard Invoker
OpenCAPIF SDK references:
- **Functions**: `update_invoker()` and `offboard_invoker()`
- **Scripts**: `invoker_capif_connector_update.py` and `invoker_capif_connector_offboarding.py`
......@@ -221,7 +230,6 @@ Onboarding is required before utilizing these functions.
## Other Features
### CAPIF Registration and Login
OpenCAPIF SDK reference:
......@@ -236,5 +244,4 @@ OpenCAPIF SDK reference:
Simplifies the logout process for admin users and removes a CAPIF user.
![Register picture](./images/flows_sdk_with_register.jpg)
......@@ -96,9 +96,9 @@ if __name__ == "__main__":
discoverer.get_tokens()
details = discoverer.invoker_capif_details
tamaño = len(details["registered_security_contexes"])
ip = details["registered_security_contexes"][tamaño-1]["aef_profiles"][0]["ip"]
port = details["registered_security_contexes"][tamaño-1]["aef_profiles"][0]["port"]
lenght = len(details["registered_security_contexes"])
ip = details["registered_security_contexes"][lenght-1]["aef_profiles"][0]["ip"]
port = details["registered_security_contexes"][lenght-1]["aef_profiles"][0]["port"]
discoverer.check_authentication["ip"] = ip
discoverer.check_authentication["port"] = port
discoverer.check_authentication()
......
......@@ -9,7 +9,7 @@ export CAPIF_PASSWORD=your_capif_password
export DEBUG_MODE=False
# INVOKER
export CAPIF_CALLBACK_URL=https://your_callback_url
export INVOKER_CAPIF_CALLBACK_URL=https://your_callback_url
# CSR (Certificate Signing Request) Configuration INVOKER
export INVOKER_CSR_COMMON_NAME=your_csr_common_name
......@@ -20,6 +20,8 @@ export INVOKER_CSR_STATE_OR_PROVINCE_NAME=your_state_or_province
export INVOKER_CSR_COUNTRY_NAME=your_country_name
export INVOKER_CSR_EMAIL_ADDRESS=your_email_address
export INVOKER_CHECK_AUTHENTICATION_IP =
export INVOKER_CHECK_AUTHENTICATION_PORT =
#DISCOVER FILTER
export DISCOVER_FILTER_API_NAME=""
export DISCOVER_FILTER_API_VERSION=""
......@@ -49,9 +51,9 @@ export PROVIDER_CSR_COUNTRY_NAME=your_country_name
export PROVIDER_CSR_EMAIL_ADDRESS=your_email_address
# Provider Specific Values
export APFS=your_apfs_value
export AEFS=your_aefs_value
export API_DESCRIPTION_PATH=/path/to/api_description
export PROVIDER_APFS=your_apfs_value
export PROVIDER_AEFS=your_aefs_value
export PROVIDER_API_DESCRIPTION_PATH=/path/to/api_description
# Publish Request Configuration
export PUBLISH_REQ_SERVICE_API_ID=your_service_api_id
......
......@@ -81,7 +81,7 @@ class capif_invoker_connector:
capif_username = os.getenv('CAPIF_USERNAME', config.get('capif_username', '')).strip()
capif_invoker_password = os.getenv('CAPIF_PASSWORD', config.get('capif_password', '')).strip()
capif_callback_url = os.getenv('CAPIF_CALLBACK_URL', invoker_config.get('capif_callback_url', '')).strip()
capif_callback_url = os.getenv('INVOKER_CAPIF_CALLBACK_URL', invoker_config.get('capif_callback_url', '')).strip()
supported_features = os.getenv('INVOKER_FOLDER', invoker_config.get('supported_features', '')).strip()
check_authentication = invoker_config.get('check_authentication', {})
self.check_authentication = {
......
......@@ -99,9 +99,9 @@ class capif_provider_connector:
csr_email_address = os.getenv('PROVIDER_CSR_EMAIL_ADDRESS', cert_generation.get('csr_email_address', '')).strip()
# Retrieve provider specific values (APFs, AEFs)
apfs = os.getenv('APFS', provider_config.get('apfs', '')).strip()
aefs = os.getenv('AEFS', provider_config.get('aefs', '')).strip()
api_description_path = os.path.abspath(os.getenv('API_DESCRIPTION_PATH', provider_config.get('api_description_path', '')).strip())
apfs = os.getenv('PROVIDER_APFS', provider_config.get('apfs', '')).strip()
aefs = os.getenv('PROVIDER_AEFS', provider_config.get('aefs', '')).strip()
api_description_path = os.path.abspath(os.getenv('PROVIDER_API_DESCRIPTION_PATH', provider_config.get('api_description_path', '')).strip())
# Check required fields and log warnings/errors
if not capif_host:
......@@ -468,7 +468,7 @@ class capif_provider_connector:
revoke = True
if custom["custOpName"] == "check-authentication":
check = False
if custom["custOpName"] == "revoke-authentication ":
if custom["custOpName"] == "revoke-authentication":
revoke = False
# If 'check-authentication' custom operation doesn't exist, add it
if check:
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment