-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get OIDC access tokens once the authentication redirect is successful #3250
Get OIDC access tokens once the authentication redirect is successful #3250
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are a few things to consider.
dashboard/src/modules/components/AuthComponent/common-components.jsx
Outdated
Show resolved
Hide resolved
dashboard/src/modules/components/AuthComponent/common-components.jsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also ... you should look in src/utils/axiosInstance.js
. We have an API
interceptor that adds the bearer token and reports authentication failures. That code ought to be handling expiration by attempting to use the refresh token to negotiate a new access token; otherwise our joy in using the new dashboard code will be shortlived. 😆
(And I appear to have a mind comment pending that I "abandoned" days ago without submitting. Nice of GitHub to remember it, I guess...)
94d4730
to
7a62855
Compare
Okay, opened for review now and I have tried to address most of the relevant comments, but many here may no longer be relevant. |
- New dependency added @react-keycloak/web and keycloak-js - Checks the SSO session by wrapping the entire App inside KeycloakProvider. - Removed the current use of login and registration related components. PBENCH-1073
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a bunch more code to be ripped out. 🙂
dashboard/src/modules/components/AuthComponent/common-components.jsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Coming along nicely. As many of Webb's comments suggest, a Prettier run would be good. We should probably add the prettier hook into our eslint config to check formatting in the CI as we do for Python, which would eliminate most concerns of that nature during reviews.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I almost kinda wish the prettierization had been a separate PR. It was a bit awkward to re-review this morning because, while the reformatting was segregated in a separate commit (thanks), there were new code changes on top of that commit. Ah, well; water over and/or under the bridge ...
Anyway, I think we're converging here. I'm still not sure I understand the flows around page reload and the interactions with cookies vs redux store as related to the OIDC session management, and a bit more clarity would help. Beyond that I think we're into streamlining and cleanup...
Wow: that's a really weird unit test failure, considering you haven't changed any server code. Hard to imagine re-submitting will make any difference, but I'm trying anyway. |
I guess re-submitting worked mysteriously 🤔 |
I'm guessing that it's a missing fixture (or a fixture scope change, or a change to a "chain" of fixture inclusions) in the test code, and that it has little or nothing to do with Server code. |
Apparently so. 😬 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These latest changes look good; we just need to conclude the discussions from the previous reviews.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. I think you should add some more to the getDatasets
error handler. Beyond that, I found what I think are a couple of unneeded async
's, a handful of unneeded ?.
's, and some other small things which you should consider addressing.
And, there are a few lingering issues from my earlier passes:
- Account creation date (can't we just remove the whole
ProfileComponent
?) - The untested
?.
result in theHeaderComponent
. - The
if
statement inauthCookies()
.
But, I think we're getting close.
) : ( | ||
<></> | ||
)} | ||
{<></>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like an orphan which should have been removed. (I.e., I think this was a placeholder for the second half of a ternary; you removed the first half, so now we don't need the "no-op" second half.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The less files formatting has been changed.
Also, imports in few files are changed from " "
to ' '
I just re-checked,
Are we not supposed to change |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good enough for now.
I think there is an orphan bit of code which should have been removed, but it's the HTML/Javascript equivalent of a no-op, so it's not worth haggling over.
And, I'm still unsettled by the if
statement in authCookies()
, but we can work on "flow" later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not thrilled about the error formatting, but this is a problem throughout the dashboard we probably need to address separately.
dispatch(showToast(DANGER, error?.response?.data?.message)); | ||
const msg = error.response?.data?.message; | ||
dispatch( | ||
showToast(DANGER, msg ? msg : `Error response: ${error.response}`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How will Javascript format a Response
object? Is that really what we want to appear in the toast? If the response body is a JSON and has message
we want to show it; it could also be JSON without a message
, or a non-JSON response payload, or there could be no payload at all. I'm not sure how "clever" we want to be here, but probably the final fallback would be the HTTP status code and the code's generic message (response.reason
, I think, in Python, though I'm not sure offhand how the Javascript response object differs.) So, maybe, just error.response.data.message
or the HTTP status and reason? (But what if we get an error
exception that doesn't even have a Response
object? In this code we're back to a stringified undefined
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How will Javascript format a Response object?
It's a valid question which I decided to punt on the principal of the perfect being the enemy of the done. This is something that we can iterate on.
Is that really what we want to appear in the toast?
Probably, not; but my instinct was that it was better than a generic (local fixed-text) message.
I'm not sure how "clever" we want to be here
Only as clever as we need to be and no cleverer. If you're reasonably sure that there will be a response.reason
, I'm OK with using that instead of the whole response
(I was hoping that Javascript would do something reasonable, and that having the whole response might be be illuminating). If we use the chaining dereference, I'm OK with seeing an undefined
in the rare case that we get an error with no other information (i.e., that's not much different from getting a literal "something went wrong" message....)
…distributed-system-analysis#3250) * Dashboard integration with keycloak - New dependency added @react-keycloak/web and keycloak-js - Checks the SSO session by wrapping the entire App inside KeycloakProvider. - Removed the current use of login and registration related components. - Removed all the changes and files that got void after this authentication change. - Also ran prettier on the entire src directory. PBENCH-1073
…distributed-system-analysis#3250) * Dashboard integration with keycloak - New dependency added @react-keycloak/web and keycloak-js - Checks the SSO session by wrapping the entire App inside KeycloakProvider. - Removed the current use of login and registration related components. - Removed all the changes and files that got void after this authentication change. - Also ran prettier on the entire src directory. PBENCH-1073
…distributed-system-analysis#3250) * Dashboard integration with keycloak - New dependency added @react-keycloak/web and keycloak-js - Checks the SSO session by wrapping the entire App inside KeycloakProvider. - Removed the current use of login and registration related components. - Removed all the changes and files that got void after this authentication change. - Also ran prettier on the entire src directory. PBENCH-1073
…distributed-system-analysis#3250) * Dashboard integration with keycloak - New dependency added @react-keycloak/web and keycloak-js - Checks the SSO session by wrapping the entire App inside KeycloakProvider. - Removed the current use of login and registration related components. - Removed all the changes and files that got void after this authentication change. - Also ran prettier on the entire src directory. PBENCH-1073
…#3250) * Dashboard integration with keycloak - New dependency added @react-keycloak/web and keycloak-js - Checks the SSO session by wrapping the entire App inside KeycloakProvider. - Removed the current use of login and registration related components. - Removed all the changes and files that got void after this authentication change. - Also ran prettier on the entire src directory. PBENCH-1073
On the Pbench Dashboard when the OIDC authentication redirect request is successful, the OIDC broker will redirect the user back to the Pbench auth page with a location header containing
session_id
andcode
. We have to use thiscode
to make a POST request against the OIDC token endpoint. If the token endpoint request is successful we log the user in and redirect the user to the overview page.The POST request might look like the following:
Note: This also makes a request to the OIDC
userinfo
endpoint to fetch and then store the user info as a state value.This PR is currently rebased on commits from PR #3233
PBENCH-1073