Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Pass OIDC config from .env to Backend and Frontend #458
Pass OIDC config from .env to Backend and Frontend #458
Changes from 6 commits
5ac8716
f666acc
cb643b7
735cbe7
8171f6c
e287887
f59a7a5
6b3b295
44c7353
7fcfeaf
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 wanted to note this warning I'm seeing about
ARG
:I don't think this is a particular problem for us, because anyone who could run
docker history
on the machine would also be able to read the .env file. Passing this information viabuild.args
doesn't seem riskier than passing it viaenvironment
. However, I wanted to mention the warning in case I'm misunderstanding something about it.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.
Right now, build-frontend.sh derives
VUE_APP_OIDC_ENABLED
from the other threeOIDC_*
variables. It'd be nice if we could derive that value somewhere prior to the Dockerfile, then pass only that value to the Dockerfile as anARG
. However, I don't know of an easy way to do that with our current setup. And again, my understanding is that this approach isn't a particular risk for us.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.
@alxndrsn and I discussed this earlier today. Instead all three
OIDC_*
variables being passed to nginx.dockerfile, now onlyOIDC_DISCOVERY_URL
will be passed. UnlikeOIDC_CLIENT_SECRET
,OIDC_DISCOVERY_URL
isn't sensitive, so there shouldn't be an issue that it is passed viaARG
. build-frontend.sh will deriveVUE_APP_OIDC_ENABLED
based only on the presence ofOIDC_DISCOVERY_URL
.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.
Even if derived from
OIDC_DISCOVERY_URL
, I think it would still be helpful to call thisOIDC_ENABLED
or similar in the frontend image, as that is what it's used for. I think seeingOIDC_DISCOVERY_URL
in the frontend would raise questions about why it's being passed there.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.
OIDC_DISCOVERY_URL
won't be visible in the JS that's built, justVUE_APP_OIDC_ENABLED
. Is there somewhere other than the JS that you're thinking about? I think we can assume that anyone examining the source will be able to determine why the variable is passed to nginx.dockerfile.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.
Alex and I chatted about this earlier today. We decided to reintroduce a separate
OIDC_ENABLED
variable so that we don't need to pass the discovery/issuer URL to the Frontend build. The user will specify theOIDC_ENABLED
variable: it's not derived from the other variables. I've made this change in a commit I just pushed.