This repository has been archived by the owner on Jul 23, 2024. It is now read-only.
Propagte security context to threads created by spring #406
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
RichardW98
approved these changes
Jun 7, 2023
RichardW98
reviewed
Jun 7, 2023
| @@ -44,4 +47,9 @@ public static void main(String[] args) { | |||
| SpringApplication.run(WorkflowServiceApplication.class, args); | |||
| } | |||
|
|
|||
| @Bean | |||
| public InitializingBean initializingBean() { | |||
There was a problem hiding this comment.
instead of this, can we add SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL) to postInit() in BeanWorkFlowRegistryImpl? or we can move it to some Configuration class. I think put it in main might not be a good idea
There was a problem hiding this comment.
configurations should subject to different profiles
rgolangh
commented
Jun 7, 2023
prebuilt-tasks/src/main/java/com/redhat/parodos/tasks/migrationtoolkit/GetAnalysisTask.java
Outdated
Show resolved
Hide resolved
Motivation All flow and task execution are async (@async) and All of them are lacking the security context. This means sending notification or any other action that needs this info is lacking it. Modification Configure the context strategy on bootup time so every thread that spring creates will inherit the security context. Result Sending notifications using the Notifier interface doesn't need any user information Gaps Workflows that are continued upon server restart are probably missing this information and we need to probably fetch the user info from the DB and rebuild the security context. Signed-off-by: Roy Golan <rgolan@redhat.com>
rgolangh
force-pushed
the
propagate-security-context-to-threads
branch
from
370a9fc
to
7991267
Compare
RichardW98
approved these changes
Jun 7, 2023
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: RichardW98 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Motivation
All flow and task execution are async (@async) and All
of them are lacking the security context. This means sending
notification or any other action that needs this info is lacking it.
Modification
Configure the context strategy on bootup time so every thread that
spring creates will inherit the security context.
Result
Sending notifications using the Notifier interface doesn't need any user
information
Gaps
Workflows that are continued upon server restart are probably missing
this information and we need to probably fetch the user info from the DB
and rebuild the security context.
Signed-off-by: Roy Golan rgolan@redhat.com