Closed Sp0Q1 closed 1 week ago
@pnzrr this and idp-wizard need to have keycloak-js
upgraded to 25.0.1
It's already fixed over here: https://github.com/p2-inc/phasetwo-admin-portal/pull/153
fixed in 25.0.1.1720077951
thanks so much! This was really quick.
@xgp @pnzrr not sure if related, but I just tested the new version and while the redirection issue seems to be resolved, I cannot get access to the idp-wizard. It redirects me to https://<domain>/auth/realms/<realm>/wizardaccess-denied
and throws a 404 there.
The user has all the org roles:
@Sp0Q1 Can you check to see if the roles are in the token that it gets?
yes, checking now.
Not sure if this is what you mean, but this is the (slightly redacted) data in the access token that is requested when browsing to the idp wizard:
{
"exp": 1720080707,
"iat": 1720080407,
"jti": "<snip/>",
"iss": "https://<domain>/auth/realms/<realm>",
"aud": "account",
"sub": "<snip/>",
"typ": "Bearer",
"azp": "idp-wizard",
"sid": "<snip/>",
"acr": "0",
"allowed-origins": [
"/*"
],
"realm_access": {
"roles": [
"default-roles-<realm>",
"offline_access",
"uma_authorization"
]
},
"resource_access": {
"account": {
"roles": [
"manage-account",
"manage-account-links",
"view-profile"
]
}
},
"scope": "openid email profile",
"email_verified": true,
"name": "firstname lastname",
"organizations": {
"<snip/>": {
"roles": [
"view-organization",
"manage-organization",
"view-members",
"manage-members",
"view-roles",
"manage-roles",
"view-invitations",
"manage-invitations",
"view-identity-providers",
"manage-identity-providers"
],
"name": "<realm>"
}
},
"preferred_username": "firstname",
"given_name": "firstname",
"locale": "nl",
"family_name": "lastname",
"email": "firstname@domain"
}
This was in the access_token
in the response of the /auth/realms/<realm>/protocol/openid-connect/token
POST request.
This was again a newly setup instance, will do some more checks now.
@Sp0Q1 It looks right. I'm able to reproduce.
@pnzrr under what conditions do we redirect to the access denied? The token call is succeeding with the correct content.
@pnzrr I think it might be in the logic of hasRealmRole/useRoleAccess that could have changed behavior in the 25
upgrade.
It works now thanks!
@pnzrr Looks like some difference/problem in loading the permissions. That hook eventually loads a true
, but tries a few times.
@Sp0Q1 @xgp taking a look now. I think you're correct that there is a loading aspect waiting for roles to populate and since it still is it is prematurely trying to route to access-denied. I may have to tweak this to render a component rather than a redirect.
How to reproduce:
image: quay.io/phasetwo/phasetwo-keycloak:25.0.1.1718907377
More details The following requests are repeated (along with some other static files) until the HTTP 431:
Expected behaviour:
image: quay.io/phasetwo/phasetwo-keycloak:25.0.1.1718907377
toimage: quay.io/phasetwo/phasetwo-keycloak:24
in the docker-compose file.