feat: custom STAC API runtime with collection transactions enabled#97
feat: custom STAC API runtime with collection transactions enabled#97hrodmn wants to merge 13 commits into
Conversation
| ) | ||
|
|
||
|
|
||
| @lru_cache(maxsize=1) |
There was a problem hiding this comment.
This cache would be caching the values being pulled out of the dict, is that right?
There was a problem hiding this comment.
Yes. load_secret_dict() caches the parsed JSON secret object keyed by ARN, so we do not hit Secrets Manager on every warm invocation. Then get_basic_auth_credentials() caches the extracted (username, password) tuple on top of that. The intent was to keep auth lookups local after the first read within a Lambda execution environment.
| validate_transaction_auth_config() | ||
| return [Depends(require_transaction_auth)] |
There was a problem hiding this comment.
This is sometimes meant to do a double validation of the auth config?
There was a problem hiding this comment.
Yes, that was intentional. I wanted one validation when wiring the protected routes so misconfiguration fails early, and another inside the request dependency so the auth guard stays self-contained and fails closed at request time too. The second check is cheap because the credential lookup is cached.
| handler = Mangum( | ||
| app, | ||
| lifespan="off", | ||
| text_mime_types=["text/", "application/"], |
There was a problem hiding this comment.
is this always meant to be broad? is there a benefit to list specific text/ or application/ types?
There was a problem hiding this comment.
A more explicit list like application/json, application/geo+json, and the other STAC/OpenAPI response types would be clearer and safer, so I can tighten that up.
There was a problem hiding this comment.
I was just following what we do in eoapi-cdk, so maybe we should consider a tighter list over there too.
2 participants
This PR adds a custom STAC API runtime for MAAP that we need in order to enable the transactions extension (for /collections routes only). The plan is to enable collection transactions for the DPS (User) STAC first so users on the MAAP Console can "reserve" collections in the DPS STAC by posting them to the DPS STAC API (via MAAP API). The assumption is that collection-wise authentication will be managed on the JPL side.
I set it up to store a basic auth username/password (stored in secrets manager) for now but eventually we will move to a more advanced authentication scheme that will work with the MAAP Keycloak.
Here is a view of the protected endpoints in the swagger ui!
While I was in here I updated some of our unit testing CI and added a local docker network that we can use to test locally.