[
https://issues.apache.org/jira/browse/SLING-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988538#comment-16988538
]
Ashish Chopra commented on SLING-8869:
--------------------------------------
bq. If an Executor with a wrong pwd is cached then the only way to evict that
executor is to recreate the DistributionTransportContext cache entirely. This
happens currently because re-configuring a credential based secret provider
will force the components referencing it to restart.
I share your understanding on this. Currently, new instances of
{{RemoteDistributionPackageImporter}} will be created each time
credential-providers is reconfigured (e.g., due to credential-update), ensuring
that HTTP transport always works with most up-to-date credentials and executors
with stale credentials aren't accessible (and are candidates for GC). This is
true for both {{DistributionAgentFactory}} impls and
{{RemoteDistributionPackageImporterFactory}}.
bq. [it works] only by luck.
Erm, to me it seems to be as-designed - unless there's another supported
mechanism that can create/update credential-providers _without_ a corresponding
creation of {{RemoteDistributionPackageImporter}} with updated credentials.
If such a mechanism exists, can you please explain it here for my better
understanding?
bq. One way to handle this would be to evict the Executor based on the returned
status code, 401 and 403.
Assuming my understanding is correct, this seems like overkill for a credential
provider that contains static-secrets.
For dynamic-secrets, (even if there is 401/403 based executor-eviction,
followed by token-reacquisition) since the secret-provider can't be explicitly
asked for a token-update (which isn't possible because there's no such
capability in the API [0]), we anyway need to rely on the secret-provider
returning the most updated token when asked for.
In current proposal HTTP Transport impl doesn't concern itself with token
expiry/regeneration/caching and dumbly asks for the credentials from
secret-provider always, letting the secret-provider deal with all the
complexities of returning most up-to-date token always, which it leverages for
transport.
Can you please help me understand the benefit of a failing HTTP call as you
propose?
[0]
https://github.com/apache/sling-org-apache-sling-distribution-api/blob/master/src/main/java/org/apache/sling/distribution/transport/DistributionTransportSecretProvider.java#L45
> SimpleHttpDistributionTransport does not refresh the secret for token based
> implementations.
> --------------------------------------------------------------------------------------------
>
> Key: SLING-8869
> URL: https://issues.apache.org/jira/browse/SLING-8869
> Project: Sling
> Issue Type: Bug
> Components: Content Distribution
> Reporter: Mohit Arora
> Assignee: Timothee Maret
> Priority: Critical
> Fix For: Content Distribution Core 0.4.2
>
> Attachments: SLING-8869-new.patch, SLING-8869.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While saving the {{contextKeyExecutor}} in {{DistributionTransportContext}}
> map, it is not expected that the secret associated with the executor could be
> expired. This can happen in case of access token based implementations where
> the token is expired after a certain period of time and has to be refreshed.
> The code to refresh the token is written in the secret provider but since the
> executor is [cached in the
> map|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/transport/impl/SimpleHttpDistributionTransport.java#L208]
> the secrets are not refreshed. It works fine for credentials based secret
> provider but not for access token based.
> cc - [~marett]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
