Skip to content
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

Extend AuthenticationStepsOperator for non-blocking resource access #586

Closed
mp911de opened this issue Sep 24, 2020 · 2 comments
Closed

Extend AuthenticationStepsOperator for non-blocking resource access #586

mp911de opened this issue Sep 24, 2020 · 2 comments
Labels
type: enhancement A general enhancement
Milestone

Comments

@mp911de
Copy link
Member

mp911de commented Sep 24, 2020

Some authentication mechanisms (Kubernetes, PCF) require file resources to read and post these as part of the login process. Right now, these mechanisms use a cached variant of the resource to avoid blocking File I/O which is unfortunate if the resources rotate. We have already AuthenticationSteps.fromSupplier(…) that accepts a supplier. If the supplier is an instance of CredentialSupplier, we should use DataBufferUtils to read the resource (assuming it's a file resource).

All other resource types could be read by using a scheduler.

See also:

@mp911de mp911de added the type: enhancement A general enhancement label Sep 24, 2020
@mp911de mp911de added this to the 2.3 RC1 milestone Sep 24, 2020
mp911de added a commit that referenced this issue Sep 24, 2020
Since AuthenticationStepsOperator is now able to use non-blocking I/O for resource access, there's no need to cache the instance keys/tokens.

See gh-586.
mp911de added a commit that referenced this issue Sep 24, 2020
Reorder methods according to their call sequence.

See gh-586.
@kawsark
Copy link

kawsark commented Oct 7, 2020

Hello @mp911de could you confirm whether this issue is only relevant for applications using the Reactive stack? Per your comment in GH-491, I think Kubernetes, PCF authentication resources are re-read prior to login as long as it is a non-Reactive stack.

Or, does this issue aim to introduce non-blocking IO which will be relevant for all applications?

Thanks a lot for the clarifications!

@mp911de
Copy link
Member Author

mp911de commented Oct 7, 2020

This change has relevance for both stacks. Given the previous limitation that authentication methods requiring File I/O could be also used in the reactive stack, we had to cache PCF certificates and the Kubernetes token file to prevent File I/O when using the reactive stack.

Since this limitation is now lifted, caching is no longer required and no longer in place so both stacks benefit from that change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants