fix: accept a table ARN as TableName in data-plane operations - #200
fix: accept a table ARN as TableName in data-plane operations#200yesyayen wants to merge 1 commit into
Conversation
Resolve a table ARN supplied in place of a bare table name to its bare name, matching Amazon DynamoDB and DynamoDB Local. Normalizes the wire TableName, batch RequestItems keys, and transact sub-op table names in the request path so authorization, validation, throttling, and echoed names all see the bare name. Index, non-table, and malformed ARNs are rejected as ValidationException. Account and region are ignored (name resolves within the caller's account), matching DynamoDB Local.
0ae86a3 to
e60ea96
Compare
|
This is an interesting one. The intent of ARNs is that they are a globally unique reference to a resource (in some contexts, at that point in time, in other contexts, over all time). See https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html for more. With that in mind, maybe we should only accept ARNs with a partition of "extenddb" and when we initialize a extenddb instance, we generate a UUID to represent the "region"? But we'd want to reconcile that with our notion of sigv4 support and ARNs we already return to the user. I think current behavior is that the server's own region (used for ARNs, stream records, etc.) defaults to us-east-1 and is configurable via server.region in extenddb.toml, and ARNs returned do use "aws". Sigh. Seems like this needs a little more discussion. |
| /// Returns `ValidationException` when `name` begins with `arn:` but is not a | ||
| /// well-formed `table/<name>` ARN. | ||
| pub fn resolve_table_arn(name: &str) -> Result<&str, DynamoDbError> { | ||
| if !name.starts_with("arn:") { |
There was a problem hiding this comment.
This method brings to mind "parse, don't validate". Is it possible that eventually some of the other ARN elements will be useful? If so, is it worth considering now parsing a table arn into its constituent parts? If it fails to parse correctly, it's invalid. Otherwise, callers can access the specific parts they need. I'd be okay with deferring this in order to resolve the immediate problem, but wanted to raise the suggestion.
3 participants
What
Resolve a table ARN supplied in place of a bare table name to its bare name, matching Amazon DynamoDB and DynamoDB Local. Normalizes the wire TableName, batch RequestItems keys, and transact sub-op table names in the request path so authorization, validation, throttling, and echoed names all see the bare name. Index, non-table, and malformed ARNs are rejected as ValidationException. Account and region are ignored (name resolves within the caller's account), matching DynamoDB Local.
Behavior: before vs Amazon DynamoDB
Captured from Amazon DynamoDB and DynamoDB Local via the AWS CLI:
GetItem/PutItem/Querywith a same-account table ARN asTableNameResourceNotFoundExceptionBatchGetItem/BatchWriteItemwith an ARNRequestItemskeyResourceNotFoundExceptionTransactGetItems/TransactWriteItemswith an ARN sub-opTableNameResourceNotFoundException.../table/T/index/i) asTableNameResourceNotFoundExceptionValidationException.../stream/T) asTableNameResourceNotFoundExceptionValidationExceptionTableNameResourceNotFoundExceptionValidationExceptionConsumedCapacity.TableName, batch response keys)ResourceNotFoundExceptionResourceNotFoundExceptionResourceNotFoundExceptionResourceNotFoundExceptionAccessDeniedException.DescribeTable) do not accept an ARN as name.Why
Conformance gaps
Closes #
Testing done
tests/test_table_arn_as_name.py: 16 dual-target casesChecklist
cargo test --workspace)cargo fmt --check)cargo clippy -- -W clippy::pedantic)Storagetrait, auth model, on-diskformat, or public CLI surface, an RFC has been accepted or is linked
below. Otherwise, an ADR captures the decision (link below).
ADR / RFC:
Breaking changes
N/A
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache License 2.0 and I agree to the Developer Certificate of
Origin (DCO). See CONTRIBUTING.md for details.