test(artifacts): demonstrate that S3ArtifactStoreGetter.get does not … #1178
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dbyron-sf
force-pushed
the
demonstrate-artifact-store-getter-auth-bug
branch
2 times, most recently
from
9069f58
to
30dfe7c
Compare
…use AuthenticatedRequest.getSpinnakerUser when authenticating with the permission evaluator. It uses SecurityContextHolder.getContext() which may be null depending how the context is propagated across threads. This is the case in some scenarios during pipeline execution in orca (e.g. using #fetchReference in an Evaluate Variables stage).
dbyron-sf
force-pushed
the
demonstrate-artifact-store-getter-auth-bug
branch
from
30dfe7c
to
1c74ba7
Compare
dbyron-sf
added a commit
to dbyron-sf/kork
that referenced
this pull request
Apr 26, 2024
so S3ArtifactStoreGetter can call a username-based hasPermission method. FiatPermissionEvaluator has this method, but using FiatPermissionEvaluator in kork would create a circular dependency. The plan is: - publish a kork jar with UserPermissionEvaluator, - consume it in fiat and change FiatPermissionEvaluator to implement UserPermissionEvaluator instead of PermissionEvaluator - publish a fiat jar and consume it everywhere - change S3ArtifactStoreGetter to use UserPermissionEvaluator to fix the bug that spinnaker#1178 generates - publish yet another kork jar and consume it everywhere to fix use of fetchReference in Evaluate Variables stages
dbyron-sf
added a commit
to dbyron-sf/kork
that referenced
this pull request
Apr 26, 2024
so S3ArtifactStoreGetter can call a username-based hasPermission method. FiatPermissionEvaluator has this method, but using FiatPermissionEvaluator in kork would create a circular dependency. The plan is: - publish a kork jar with UserPermissionEvaluator, - consume it in fiat and change FiatPermissionEvaluator to implement UserPermissionEvaluator instead of PermissionEvaluator - publish a fiat jar and consume it everywhere - change S3ArtifactStoreGetter to use UserPermissionEvaluator to fix the bug that spinnaker#1178 demonstrates - publish yet another kork jar and consume it everywhere to fix use of fetchReference in Evaluate Variables stages
xibz
approved these changes
Apr 27, 2024
mergify bot
added a commit
that referenced
this pull request
Apr 27, 2024
so S3ArtifactStoreGetter can call a username-based hasPermission method. FiatPermissionEvaluator has this method, but using FiatPermissionEvaluator in kork would create a circular dependency. The plan is: - publish a kork jar with UserPermissionEvaluator, - consume it in fiat and change FiatPermissionEvaluator to implement UserPermissionEvaluator instead of PermissionEvaluator - publish a fiat jar and consume it everywhere - change S3ArtifactStoreGetter to use UserPermissionEvaluator to fix the bug that #1178 demonstrates - publish yet another kork jar and consume it everywhere to fix use of fetchReference in Evaluate Variables stages Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
dbyron-sf
added a commit
to dbyron-sf/kork
that referenced
this pull request
Apr 27, 2024
…rUser in S3ArtifactStoreGetter instead of SecurityContextHolder.getContext() which might be null. Previously hasAuthorization would only user userId for logging. Now it's used for authentication too. This fixes the bug that spinnaker#1178 demonstrates.
dbyron-sf
added a commit
that referenced
this pull request
Apr 28, 2024
…rUser in S3ArtifactStoreGetter (#1180) * chore(build): give local gradle invocations more memory The same amount that github actions uses, to avoid errors like: Expiring Daemon because JVM heap space is exhausted Expiring Daemon because JVM heap space is exhausted FAILURE: Build failed with an exception. * What went wrong: Gradle build daemon has been stopped: JVM garbage collector thrashing and after running out of JVM memory and after running out of JVM memory * fix(artifacts): authenticate against AuthenticatedRequest.getSpinnakerUser in S3ArtifactStoreGetter instead of SecurityContextHolder.getContext() which might be null. Previously hasAuthorization would only user userId for logging. Now it's used for authentication too. This fixes the bug that #1178 demonstrates.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
…use AuthenticatedRequest.getSpinnakerUser
when authenticating with the permission evaluator. It uses SecurityContextHolder.getContext() which may be null depending how the context is propagated across threads. This is the case in some scenarios during pipeline execution in orca (e.g. using #fetchReference in an Evaluate Variables stage).