feat: dynamic auth via authentication extension#783
feat: dynamic auth via authentication extension#783alukach wants to merge 6 commits intoradiantearth:mainfrom
Conversation
|
Thanks. Some additional context is in the old PR: moregeo-it#4 |
|
Status update on this: it's somewhat working. What works: If you navigate to a catalog's root, it can retrieve the catalog metadata content and determine which URLs require auth and properly inform the user that they need to log in to list Collections. Once successfully completing the auth flow, the user can navigate through Collections and into Items. What doesn't work: If you load any guarded path on a catalog (e.g. reloading an Item view), the auth credentials are lost along with the metadata about how a user should authenticate with the catalog. It feels like the right solution may be to configure the STAC Browser to fetch the catalog document when a sub-document (e.g. collection or item) so that it can properly configure the auth requirements of the catalog. Perhaps this should only be done in reaction to a 401 response code from the STAC server. Screen.Recording.2026-02-18.at.9.16.22.AM.mov@m-mohr any guidance? |
|
Okay, I took a crack at doing a proactive fetch of the catalog root when a subpath is loaded. It seems to work with my manual testing! I also added a load of Screen.Recording.2026-02-18.at.1.58.05.PM.mov |
|
Thanks, I'll have a look soon. I have quite a list of todos still on my list, so it may take couple of days at least. |
There was a problem hiding this comment.
The removal is - if I remember correctly - for cases where you are in the "demo" mode (i.e. no catalogUrl set) and you switch between catalogs. Then the authConfig would be applied to the wrong catalog. I guess we need to store it differently, e.g. per catalogUrl or so.
| // Make sure we have all authentication details | ||
| await cx.dispatch("auth/waitForAuth"); | ||
|
|
||
| // Proactively load root catalog to discover auth:schemes before sub-document fetch |
There was a problem hiding this comment.
That we have to extend the load function so significantly, making it even more complex shows why I'm currently working on refactoring the whole store / database approach. It just gets unmainable. We had so many regressions in the past by change small things here that I'm hesitating to apply such significant changes here without first introducing more tests. I also want to migrate to Pinia soon and then rework the whole database, so I'm not sure it's the right call to add this right now. I want us to support this, but maybe a better time is when we have actually have some other groundwork done?
Side question: Not 100% sure how to provide client IDs for OIDC through the STAC Auth extension? Thoughts?
| } | ||
| cx.commit('resetActions'); | ||
| }, | ||
| async configureFromSchemes(cx, authSchemes) { |
There was a problem hiding this comment.
At the same time we probably want to deprecate the authConfig-based configuration that we currently support to read from the catalog. (more a note to myself.)
m-mohr
force-pushed
the
main
branch
3 times, most recently
from
fc148d6 to
61cbb18
Compare
2 participants
Currently, we expect that a user provides authentication information to STAC Browser via configuration. However, that configuration could also be read from the STAC Catalog if it supports the Authentication Extension.
This PR represents an experiment in dynamically loading auth configuration from the STAC Catalog. Manual testing with a local catalog fronted with the STAC Auth Proxy (both catalog and proxy are defined in developmentseed/stac-auth-proxy/docker-compose.yaml) seems to be working as expected.