Product/components used and version/fix level:
Cumulocity IoT Backend 1020.296.0
Python Microservice API 2.1.4
Detailed explanation of the problem:
The /application/currentApplication/settings endpoint behaves different as expected.
The Respose is “{‘Key1’:‘Value1’ , ‘Key2’:‘Value2’, … }”,
instead of the Respose type from the API Documentation
[
{
“key”: “hostkey-autosave”,
“valueSchema”:{
“type”: “boolean”},
“defaultValue”: “true”,
“editable”: true,
“inheritFromOwner”: true}
]
Question related to a free trial, or to a production (customer) instance?
I saw it while trying to get Application Settings with the Python API.
Is the documentation outdated or is there a Backend error?
Can you elaborate how you defined the settings? Via the manifest?
I used the Manifest Documentation as an example. So yeah via the Manifest. until now I always just used Tenant options defined in my Sourcecode, but I wanted to get rid of the Tenant Option Admin Role.
To be honest, I don’t understand the use case here. You don’t want to use tenant options (why?) and instead want to use application settings? How? How do you want to update them?
If you have settings/data that needs to be updated by non-admins, I’d just use a known inventory object for that. Is that no option?
Sorry that wasn’t clear. I currently use a Tenant Option to Store an API Key as credetials. For the microservice to read it, I need to give the microservice the ROLE_OPTION_MANAGEMENT_READ. I’d rather use the manifest settings, this way the microservice has one less permission I need to keep track of, and it can’t access Tenant Options it isn’t supposed to, like other API Keys. The settings are still Tenant Options, what makes it so great, for updating Keys …
Hope thats good enough of an explanation.
I think Lucas use case is to have pre-defined settings provided by the microservice manifest and when retrieved they look differently then documented in the API description.
So I think this looks like a documentation issue as the sample response should look differently. I guess what is displayed is the schema of the manifest
@Thomas_Winkler2 @Joerg_Hartmann Can you check if the API documentation is correct in this case?
1 Like
You could use a variant of the encrypted tenant options, see this post.
So if you start with a tenant option using a key with the credentials. prefix. But this value would still be accessible by other microservices, so to prevent this, you could just encrypt the tenant option value using the microservice’s bootstrap password (or some other secret which is only known to the microservice). That way only the intended microservice would be able to read and decrypt the value.