Thumbnails with authentication (header) can't be loaded

[m-mohr]

Thumbnails with authentication (header) can't be loaded as the HTML img tags don't support it. We can consider loading them via JS if needed and using https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL_static we can create a data url for the img tag.

[m-mohr]

This looks easy on first sight, but is not supported by the underlying UI library, so it's actually more difficult to implement than expected.

[vcaraulean]

@m-mohr
I went through a couple of sessions with LLMs and here are the results of the analysis.
The problem is larger in scope than thumbnails...

Summary

In STAC Browser, STAC JSON requests are authenticated through the existing store request pipeline, but several image assets are still loaded directly with plain <img src="..."> URLs. This causes thumbnails, icons, and logos to fail with 401 when authentication must be sent in HTTP headers, such as OIDC/Bearer, Basic auth, or API keys in headers.

The issue is real, but it needs to be stated precisely: it affects image assets that require authenticated requests and are within the app’s private-data auth scope. In this codebase, auth query parameters and auth headers are only attached to URLs that are considered part of the catalog or explicitly allowed through allowedDomains. That means the problem is not just “images are unauthenticated,” but “direct browser image loading bypasses the store request/auth logic for eligible authenticated asset URLs.”

Analysis

Current STAC/API/catalog requests go through stacRequestOptions() / stacRequest(), which apply:

• query auth via getRequestUrl()
• header auth via requestHeaders

However, several image paths bypass that logic and use getAbsoluteUrl() directly in templates or derived card props. The affected surface includes:

• src/components/Thumbnails.vue
• src/components/StacLink.vue
• src/StacBrowser.vue
• src/components/CardMixin.js

A further constraint is that the app intentionally only sends private auth data to URLs inside the catalog scope or matching allowedDomains. So even a JS fetch/blob-based image loader will not solve every external-image case unless the target domain is already eligible to receive auth.

There is also a related gap for thumbnail open/download behavior: even if image display is fixed with blob URLs, raw <a href="..."> links to protected assets will still fail for header-authenticated resources.

Recommendations

Use a shared media-auth resolution layer rather than hardcoding logic separately in each component. The recommended behavior is:

• use getRequestUrl() for assets that only need query-based auth
• keep direct URLs for public assets
• fall back to authenticated JS fetch + blob: URL when headers are required and the asset URL is allowed to receive auth

This approach is a good fit for the SPA, but it should be described as a fallback for header-authenticated images, not a universal solution. It still depends on CORS support for authenticated JS requests.

Scope the fix across all current image consumers, not only thumbnails. Also include thumbnail open/download behavior, and ensure the implementation handles object URL cleanup, auth changes, and lazy loading to avoid regressions in memory use and performance.

[m-mohr]

Yes, that's also my understanding. It happends in different places and we need to fix them all, but not all of them are directly under our control. It involves libraries such as Bootstrap Vue Next and OpenLayers, for example. I'd still want to try to fix it at some point, but the only workaround for now is to use either a query based authentication (see below) or to make the thumbnails public.

The getAbsoluteUrl vs getRequestUrl we can probably solve soon to allow query based authentication, if someone has a need for it now.

[vcaraulean]

The getAbsoluteUrl vs getRequestUrl we can probably solve soon to allow query based authentication

A proper solution should cover all authentication methods.

I think we can fix as much as we can in the scope of stac-browser. Then move on & review dependencies as well...

[m-mohr]

Sure, but the fix in only stac browser would be incomplete as well, then thumbnails would work in some parts of the browser but not the other. So my feeling is that allowing additional but not all authentication methods that work through the whole codebase is better than supporting all authentication methods only partially. That at least gives consistent and easy to document behaviour. In the long run it would be great to support everything of course, but it's not quite under our control ;-)