2 réponses
- Le plus récent
- Le plus de votes
- La plupart des commentaires
1
This can indeed be done as specified in this documentation. Should you use the following resource
arn:aws:execute-api:region:account-id:api-id/stage-name/*/foo/bar/*
the policy will apply to all methods under sub-resources of /foo/bar/
. For example, an allow there in authorizer policy will not allow methods under /foo
, only for sub-resources under /foo/bar/
.
Using a wildcard * for the http verb segment won't have an impact on later resource segment unless it is the last segment. Only the * in last segment in this example will match everything to right. Do refer to example resource expressions here for details.
Contenus pertinents
- demandé il y a 7 mois
- demandé il y a un an
- demandé il y a 8 mois
- demandé il y a 3 mois
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 3 ans
Okay, thanks! So, per the examples, it looks like in the format
arn:aws:execute-api:region:account-id:api-id/stage-name/HTTP-VERB/resource-path-specifier
it is possible to use a wildcard in place ofstage-name
and/orHTTP-VERB
and still specifyresource-path-specifier
which may also include a wildcard at the end.Is it possible, then, to also use multiple wildcards in the
resource-path-specifier
? For example, could I use a wildcard to match a path variable in my API Gateway resource - e.g./foo/bar/*/allowed
would allow access to/foo/bar/{id}/allowed
but deny access to any other sub-resource of/foo/bar/{id}/
?/foo/bar/*/allowed
should work as you expect, allowingallowed
sub-resource but implicitly denying other sub-resources