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
The batch job results are provided as "signed" URLs. If you share the URLs, you can't revoke access except you delete the results. But maybe you want to keep the results, but just revoke access to the URLs you may have shared with others. Thus it could be useful to have an API endpoint to revoke the old signed URLs and generate new "signed" URLs.
The text was updated successfully, but these errors were encountered:
I searched around a bit to find info or example implementations on revoking signed URLs but the results were disappointing so far. It seems that the most common approach to improve security is "use short expiration time" (order of minutes). The big implementations like AWS and google cloud don't seem to support revoking of signed URLs at all, except for nuclear options along the lines of "remove the resource" or "revoke the permissions of the resource owner".
So I wonder if there are some pitfalls to this feature request so that no backend will implement it in practice.
Yes, we will likely need to get more experience with this functionality first. It would also be interesting what other functionality may be required for batch job results (and/or the PATCH endpoint) so that we can figure out how to combine it.
The aim was to get a proposal up for experiments, but I doubt we'll release this in 1.1.
The batch job results are provided as "signed" URLs. If you share the URLs, you can't revoke access except you delete the results. But maybe you want to keep the results, but just revoke access to the URLs you may have shared with others. Thus it could be useful to have an API endpoint to revoke the old signed URLs and generate new "signed" URLs.
The text was updated successfully, but these errors were encountered: