...
Code Block | ||||
---|---|---|---|---|
| ||||
/** * Constructor with only required parameters */ public Policy(String id, String name) { this.id= id; } |
Handling serviceId in Request Bodies and Bearer Tokens
Current Implementation
In the current implementation, the `serviceId` can be set in the body of a request and is defined as optional. The default value for `serviceId` in `PolicyObjectInformation` (PolicyApi) is a space, which accommodates cases where the `serviceId` might be missing. However, in the `ServiceApi`, the `serviceId` is required, for example, when creating a service.
Ideal Implementation
The use of a space as a default value for `serviceId` is a workaround to handle missing IDs. Ideally, the `serviceId` should be extracted from a bearer token. This can be done by decoding a JWT token using built-in Java functions.
Here’s a sample code snippet to decode a JWT token and extract the `serviceId`:
Code Block | ||||
---|---|---|---|---|
| ||||
String[] chunks = token.split("\\.");
Base64.Decoder decoder = Base64.getUrlDecoder();
String header = new String(decoder.decode(chunks[0]));
String payload = new String(decoder.decode(chunks[1]));
JsonObject jsonObject = new JsonObject();
jsonObject.add("payload", JsonParser.parseString(payload));
String serviceId = jsonObject.getAsJsonObject("payload").get("serviceId").getAsString(); //if the json token has the field serviceId |
Integrating with Existing Code
In the codebase, there is already a function to get the token located in the class:
org.onap.ccsdk.oran.a1policymanagementservice.controllers.authorization.AuthorizationCheck
String getAuthToken(Map<String, String> httpHeaders)
Bearer Token in Headers
The bearer token would be passed during the API call via headers as follows:
"Authorization: Bearer <bearer_token>"
By extracting the serviceId from the bearer token, we can ensure that the `serviceId` is always available and accurate, enhancing the security and reliability of the API.
TODO and topic to follow
- Evaluate the necessity of optional fields: Determine if certain optional fields can be removed or if their use can be better documented to avoid dead data.
- Consider adopting more specific schemas for critical operations: This can improve both the documentation and the generated code quality. Leverage OpenAPI Features: Use OpenAPI's advanced features like `allOf`,
- Prepare for code adaptations: Implement patterns like Adapter/Builder/Transformer to handle translations between similar objects, facilitating easier maintenance and adaptation to specification changes.
- Regular compliance checks.
...