You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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?
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.
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 ofCredentialSupplier
, we should useDataBufferUtils
to read the resource (assuming it's a file resource).All other resource types could be read by using a scheduler.
See also:
The text was updated successfully, but these errors were encountered: