Skip to content

GEOMESA-3581 Base64-encode authorization credentials#3585

Open
cwdobbins wants to merge 1 commit into
locationtech:mainfrom
cwdobbins:feature/base64-encode-auths
Open

GEOMESA-3581 Base64-encode authorization credentials#3585
cwdobbins wants to merge 1 commit into
locationtech:mainfrom
cwdobbins:feature/base64-encode-auths

Conversation

@cwdobbins

Copy link
Copy Markdown
Contributor

Summary

Changes the authorization encoding between geomesa-trino-datastore and the spatial_iceberg connector from a pipe-delimited list to a single base64url-encoded value: auths:<base64url(join(tokens, ","))>

The Trino JDBC extraCredentials property is name:value pairs with ;/: as structural delimiters, and the previous pipe-joined value shared its alphabet with that format — requiring delimiter validation on both ends to prevent a spoofed token from being re-split into authorizations that were never issued. The base64url alphabet (A-Za-z0-9-_) cannot collide with the delimiters, making the transport injection-proof.

Changes

geomesa-trino-datastore

  • TrinoDataStore.connectionProperties comma-joins the validated tokens and base64url encodes the result into the auths extra credential

geomesa-trino-plugin

  • ExtraCredentialAuthorizationResolver base64url-decodes the credential value (padded or unpadded accepted) before tokenizing. A value that is not valid base64 resolves to no authorizations. The decoded payload is still split liberally on
    comma/pipe/whitespace, so mesh-injected headers can encode whatever list format they already carry.

@cwdobbins
cwdobbins force-pushed the feature/base64-encode-auths branch from c13cc0a to 9878ce9 Compare July 14, 2026 19:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant