Add an option to use pre-signed urls for tiles and thumbnails to avoid cookies.
I think we already process tokens as part of URLs, so this would be changing the client code to (a) get a short-lived token if the one it has isn't fresh enough, (b) add the token to any url that is currently authenticated via cookie.
How will this affect browser-side caching?
We have cookie-authenticated endpoints in the annotations, but I don't think we need to worry about those -- all of those should be RESTful requests that can take auth headers. The main endpoint methods are getTile, getTilesThumbnail, getTilesRegion, getTilesPixel, getAssociatedImage, tileFrames, tileFramesQuadInfo. All of these would need to pass the short-lived token, and, if used in, for instance, a tile viewer, would need some update mechanism when the token has to rotate.
Pedantically, this probably isn't using pre-signed urls but short-lived token urls.
Add an option to use pre-signed urls for tiles and thumbnails to avoid cookies.
I think we already process tokens as part of URLs, so this would be changing the client code to (a) get a short-lived token if the one it has isn't fresh enough, (b) add the token to any url that is currently authenticated via cookie.
How will this affect browser-side caching?
We have cookie-authenticated endpoints in the annotations, but I don't think we need to worry about those -- all of those should be RESTful requests that can take auth headers. The main endpoint methods are getTile, getTilesThumbnail, getTilesRegion, getTilesPixel, getAssociatedImage, tileFrames, tileFramesQuadInfo. All of these would need to pass the short-lived token, and, if used in, for instance, a tile viewer, would need some update mechanism when the token has to rotate.
Pedantically, this probably isn't using pre-signed urls but short-lived token urls.