-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix SNS cross-account issues with Subscriptions #10819
Conversation
LocalStack Community integration with Pro 2 files ±0 2 suites ±0 1h 37m 31s ⏱️ +21s Results for commit 02d9552. ± Comparison against base commit cac2d03. This pull request removes 12 and adds 20 tests. Note that renamed tests count towards both.
♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of work in there, congrats for keeping all that easily readable and adding a lot of meaningful tests.
I added most of my comments before realising that most of the SubscriptionFilter
class was a refactor... Some of them might not be as relevant to your current task then.
The only missing part I see is the lack of support for "event":[{"anything-but": {"prefix": "order-"}}]
. Let me know if you feel this is better suited for a follow up work.
self, filter_policy: dict, message_attributes: dict | ||
): | ||
for criteria, conditions in filter_policy.items(): | ||
if not self._evaluate_filter_policy_conditions_on_attribute( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How big can the message attributes get? Could we transform it into a dict to share the self._evaluate_nested_filter_policy_on_dict
implementation?
In the end it might not be worth it, since we would need to loop over it twice and it would take a bit extra memory, but reusing the implementation could make it easier to maintain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, the biggest difference is that MessageAttributes
can only be on one level, they can't have nested dict. So the logic is much simpler there. I think we could maybe join the 2 implementations, but not sure if worth it. You technically can have objects inside the message for MessageAttributes
, but the behavior is undefined from the documentation. We could have a look in the follow up, as you said, this was just moved around and will be updated with the next PR #10691
# the remaining conditions require the value to not be None | ||
return False | ||
elif anything_but := condition.get("anything-but"): | ||
return value not in anything_but |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"anything-but" can also be a "prefix" https://docs.aws.amazon.com/sns/latest/dg/string-value-matching.html#string-anything-but-matching-prefix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! This is not supported yet, and we also do not support suffix
and equals-ignore-case
, which will be supported by #10691. I could try to sneak the anything-but
into prefix
in there as well, but kept this as minimal as I could be, as the PR got big pretty quickly.
|
||
if operator not in (">", ">="): | ||
raise InvalidParameterException( | ||
f"{self.error_prefix}FilterPolicy: Too many elements in numeric expression" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really? That is the error that aws will return if you place the <
before >
? That sounds silly! 🤣
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it's a bit weird, the errors are not too expressive I'd say 😅
24b28e4
to
02d9552
Compare
Motivation
Follow up from #10788
We now had issues around accessing subscriptions made by another account for
SetSubscriptionAttributes
, which has extensive validations of theFilterPolicy
field.The issue was the same as before, Moto was not saving the subscription in the right backend for the topic account.
We were currently blocked for #10691 because the validation of filter policies containing
$or
was incorrect, so it was the right opportunity to move the validation inside LocalStack, and remove usage of moto around SNS Subscriptions. We were already saving and using theSubscription
data from our store only, and used moto for additional validation.As of today,
Topic
is still stored in moto and extended in LocalStack, and mocked operations around A2P (SMS, and Platform Applications/Endpoint, related to mobile notifications) are still done by moto.Changes
FilterPolicy
in its own file as it was becoming consequent, and we added a few more.TestSNSFilterPolicyConditions
class intest_sns_filter_policy.py
contains the new testscall_moto
andcall_moto_with_request
in the SNS providerHTTP
subscriptions (returningpending confirmation
instead of the ARN if the subscription is still pending confirmation, except ifReturnSubscriptionArn
is set totrue
).test_http_subscription_response
intest_sns.py