[
https://issues.apache.org/jira/browse/OAK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Ryan updated OAK-9710:
---------------------------
Description:
When you request a direct download URI from cloud blob storage, the TTL that is
specified for the URI is set to a default value that is specified in
configuration.
The proposal here is to consider extending the capabilities of requesting a
direct download URI such that a client can specify their own TTL, *so long as*
that TTL does not exceed a maximum value specified in the configuration.
In other words - suppose the default configured TTL is 1800 (30 minutes) and
the configured max TTL is 3600 (60 minutes). In this case:
* A client that does not specify any other TTL value would get URIs that
expire in 1800 seconds.
* A client that chooses to specify a TTL value could provide any value greater
than 0 but less than or equal to 3600 seconds.
* Specifying a TTL value of over 3600 would be an error condition.
* Specifying a TTL value of 0 would be an error condition.
* Specifying a TTL value of less than 0 would be the same as the default value
(-1), meaning to use the configured value (i.e. 1800 seconds).
The maximum TTL value would be considered an optional configuration value. If
not specified, the default configured TTL would be used (which is required to
enable the direct download feature). If specified but lower than the default,
the actual max would be the default value (i.e. {{{}max(default TTL, max
TTL){}}}).
What should happen if an error condition should occur? Typically in the direct
download code an error results in the return of a {{null}} value for the URI,
accompanied by a log message - so that'd be my proposal for this situation also.
was:
When you request a direct download URI from cloud blob storage, the TTL that is
specified for the URI is set to a default value that is specified in
configuration.
We could consider extending the capabilities of requesting a direct download
URI such that a client can specify their own TTL, *so long as* that TTL does
not exceed the value specified in the configuration. This would allow a client
to request a more restrictive-use URI, but not the opposite.
In other words - supposing the default configured TTL is 1800 (30 minutes). In
this case:
* A client that does not specify any other TTL value would get URIs that
expire in 1800 seconds.
* A client that chooses to specify a TTL value could provide any value greater
than 0 but less than or equal to 1800 seconds.
* Specifying a TTL value of over 1800 would be an error condition.
* Specifying a TTL value of 0 would be an error condition.
* Specifying a TTL value of less than 0 would be the same as the default value
(-1), meaning to use the configured value.
What error condition should occur? Typically in the direct download code an
error results in the return of a {{null}} value for the URI, accompanied by a
log message - so that'd be my proposal for this situation also.
> Allow direct download client to specify a shorter signed URI TTL
> ----------------------------------------------------------------
>
> Key: OAK-9710
> URL: https://issues.apache.org/jira/browse/OAK-9710
> Project: Jackrabbit Oak
> Issue Type: Story
> Components: blob-cloud, blob-cloud-azure, blob-plugins
> Affects Versions: 1.42.0
> Reporter: Matt Ryan
> Assignee: Matt Ryan
> Priority: Major
>
> When you request a direct download URI from cloud blob storage, the TTL that
> is specified for the URI is set to a default value that is specified in
> configuration.
> The proposal here is to consider extending the capabilities of requesting a
> direct download URI such that a client can specify their own TTL, *so long
> as* that TTL does not exceed a maximum value specified in the configuration.
> In other words - suppose the default configured TTL is 1800 (30 minutes) and
> the configured max TTL is 3600 (60 minutes). In this case:
> * A client that does not specify any other TTL value would get URIs that
> expire in 1800 seconds.
> * A client that chooses to specify a TTL value could provide any value
> greater than 0 but less than or equal to 3600 seconds.
> * Specifying a TTL value of over 3600 would be an error condition.
> * Specifying a TTL value of 0 would be an error condition.
> * Specifying a TTL value of less than 0 would be the same as the default
> value (-1), meaning to use the configured value (i.e. 1800 seconds).
> The maximum TTL value would be considered an optional configuration value.
> If not specified, the default configured TTL would be used (which is required
> to enable the direct download feature). If specified but lower than the
> default, the actual max would be the default value (i.e. {{{}max(default TTL,
> max TTL){}}}).
> What should happen if an error condition should occur? Typically in the
> direct download code an error results in the return of a {{null}} value for
> the URI, accompanied by a log message - so that'd be my proposal for this
> situation also.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
