-
Notifications
You must be signed in to change notification settings - Fork 16
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
SPA - OIDC integration following the design implemented on the PoC #558
base: authentication-oidc
Are you sure you want to change the base?
Conversation
…tibility with bearer auth feature flag
@ekraffmiller Back to Ready For Review .. There was a single test failing when checking a checkbox (Terms Of Use), this was only happening in github actions, this was because the interactivity was happening too fast, I added a 300ms |
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 great, it's so nice to have OIDC in the SPA! 🎉
Regarding the testing, would it simplify things to add a script to docker-compose that completes the signup process for the OpenID users, and updates their permissions? That way it wouldn't have to be done for individual tests.
I did find one issue when I tried to give the Dataverse User account permissions through JSF. The Dataverse User isn't shown on the DataverseAdmin's dashboard, even though a user that I create within Dataverse is there. I can create a separate issue for that.
Also, what is the plan for Dataverse built-in users when we deploy to production? Will Dataverse be configured to do OpenID authentication for those users?
throw new Error('Network response was not ok') | ||
} | ||
return response.blob() | ||
return axiosInstance |
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.
Is this going call to the API going to be replaced with a call to js-dataverse? If so, can we add a todo?
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 think this was a decision to avoid creating a use case just for this (I wasn't around at the time) and the idea is to keep it that way, I just switch from using a simple fetch to the axios instance I created which automatically sends the authentication token.
DataverseApiAuthMechanism.BEARER_TOKEN, | ||
undefined, | ||
`${OIDC_AUTH_CONFIG.LOCAL_STORAGE_KEY_PREFIX}token` | ||
) |
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 think I'm missing something - why does this ApiConfig.init() need to be run at the beginning every integration test, but it doesn't need to be run in the e2e tests?
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.
You are right, there was no need, I don't know what I was thinking, what I did now is to initiate all the tests with the bearer token method from the Setup tests and removed all the unnecessary initializations in the integration tests and that's it, everything works in my local, let's hope they pass the tests in github actions. 🤞🏼
…ary api config inits on all integration tests
@ekraffmiller thanks for the review!
For these two blocks I think we can keep iterating and thinking about it on this same branch that this PR points to (remember it doesn't point to
On this last comment, perhaps we can check with Guillermo on Monday to find out what is going on. |
What this PR does / why we need it:
Change SPA authentication method to use Keycloak as OIDC provider using PKCE based on an initial PoC.
Which issue(s) this PR closes:
Special notes for your reviewer:
This PR does not point to the
develop
branch but to a separate branch ( authentication-oidc ), the idea is in another PR to configure the deployment to another environment that is not Beta maybe to be able to test this not only locally before merging to develop.All unit tests and e2e tests are working now with this new authentication method.
Application terms of use are empty for now as we don't have an API endpoint for it yet.
Suggestions on how to test this:
Step 1: Run the Development Environment
npm i
.cd packages/design-system && npm i && npm run build
.cd ../../
..env
file similar to.env.example
, with the variableVITE_DATAVERSE_BACKEND_URL=http://localhost:8000
.dev-env/.env
file is filled with the appropriate data. For theREGISTRY
variable, please setghcr.io
, as we will use a PR-generated dataverse image.cd dev-env
../run-env.sh 10959-bearer-token-auth-ext
.Step 2: Test the feature in the SPA
Another path:
Does this PR introduce a user interface change? If mockups are available, please link/include them here:
signup-success.mov
Is there a release notes update needed for this change?:
No
Additional documentation:
No