uaa-cli
uaa-cli copied to clipboard
uaa list-clients: json: cannot unmarshal string into Go struct field Client.resource_ids of type []string
Version
$ uaa version
0.7.0 8b3ea1f
Command
uaa list-clients
Returns
An unknown error occurred while parsing response from https://uaa.run.markspcffoundry.com/oauth/clients?count=100&sortOrder=ascending&startIndex=1. Response was <18150 characters of redacted json>: json: cannot unmarshal string into Go struct field Client.resource_ids of type []string
The <18150 bytes of redacted json> is from me, not the uaa client.
If I take the 18150 characters of json and pipe through jq it processes successfully.
If I run the command a second time with the --verbose
flag, and compare the json from that output to the json in the error message, it is a perfect match.
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/168193674
The labels on this github issue will be updated when the story is started.
- According to UAA API specs,
GET /oauth/clients/{client_id}
should returnresource_ids
attribute as anArray
. -
Actual UAA implementations return
resource_ids
either as an array of strings or as a simple string.
Example of querying UAA v4.19.2:
$ uaa curl /oauth/clients|jq '.resources[]|select(.resource_ids|type == "string")'
{
"scope": [
"cloud_controller.admin",
"cloud_controller.read",
"cloud_controller.write",
"openid",
"zones.*.*",
"zones.*.*.*",
"zones.read",
"zones.write",
"scim.read"
],
"client_id": "identity",
"resource_ids": "none",
"authorized_grant_types": [
"authorization_code",
"client_credentials",
"refresh_token"
],
"redirect_uri": [
"REDACTED",
"REDACTED*"
],
"autoapprove": true,
"authorities": [
"zones.read",
"zones.write",
"scim.zones",
"uaa.resource",
"uaa.admin",
"cloud_controller.admin"
],
"lastModified": 1551175600000
}
So, even with uaa-cli
is API compliant, it is not compatible with the actual UAA servers.
Just to follow up
$ uaa version 0.10.0 8626b94
OM/PAS = 2.8.5
Problem persists.
Hello. The /oauth/clients
api does have some quirks and I agree that this cli should handle those.
We don't have plans to start work on this CLI again at the moment, but if we do this issue will be addressed then.