Closed day0ops closed 2 years ago
I couldnt reproduce this myself. Tried both 1.2.4
and 1.2.5
.
And nothing screamed at me looking at this config
They also mentioned that if the Environment is created in Caps its being accepted but not able to create API keys. Trying to gather more information on this
I've attempted to reproduce and done static code analysis
My conclusion is basically that the logic looks good and it seems possible/likely that the user they’re logging in with isn’t actually a member of the group and that since AllApisPublicViewable
is true
on their Portal they can still see the Product(s) listed but because they’re not authorized to interact with them they see no Plans
One way to test if that was the issue would be to set AllApisPublicViewable to false and see if the Product(s) are visible at all
Here is what the page looks like under different circumstances:
Authenticated user is a member of a group that has access to "Petstore Product":
Authenticated user is not a member of a group that has access to "Petstore Product" and Portal has AllApisPublicViewable
set to true
:
Authenticated user is not a member of a group that has access to "Petstore Product" and Portal has AllApisPublicViewable
set to false
:
Note that the UI does not seem to reflect a login for a user that cannot view any Products. In the above screenshot I am logged in even though that is not reflected in the UI. It is still possible to view the above view by manually navigating to /keys
. This likely constitutes a separate bug.
We should try to determine if the customer is authenticating with users that have access to the Product(s) in question and proceed from there.
The root cause of the issue was that Keycload was prepending a /
to the group name, causing authenticated users not to have access to APIs as described above.
The customer is able to resolve the issue without code change, presumably by adding the /
to the groupNames
entry in the Group CR.
While this issue can be closed, it may be worthwhile to document this behavior of Keycloak or otherwise improve our documentation to highlight the distinction between authenticating to the Portal and having access to APIs.
Describe the bug Customer ran into this strange behaviour of not showing the API usages (on portal) when using OIDC as the auth mechanism. We double checked basic auth which seemed fine.
Logs didn't show any issues.
Posting the config,
Groups,
Portal,
Environment,
APIProduct,
To Reproduce Steps to reproduce the behavior:
Expected behavior API usages should have been shown when logged in
Additional context Add any other context about the problem here, e.g.
1.2.4
openshift