[
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.
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.
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.
> 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.
> 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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
