You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If two teams in the same organization had two accounts, it would be impossible for the SQS transport to send messages from one account to the other without using the transport bridge. It would be interesting to analyze if it would be possible and beneficial for the transport to offer this directly.
Where queues are currently just a name, I would imagine that the transport would need to be smart enough to recognize the difference between just a name, which must be a local queue, and something like a full queue ARN that would allow sending to a different account if IAM permissions were set appropriately.
I would also imagine headers would have to be added or modified so that reply messages could be properly routed, and so that failed messages processed by a centralized ServiceControl instance could be replayed to the correct account as well.
Analysis would also need to include whether there are security risks inherent in transmitting a full queue ARN which includes information like the account number, and what could be done to mitigate those risks.
The text was updated successfully, but these errors were encountered:
In theory when the bridge would be allowed to be hosted as part of the endpoint as mentioned in Particular/NServiceBus.MessagingBridge#118 the transport wouldn't have to be extended with this capability.
If two teams in the same organization had two accounts, it would be impossible for the SQS transport to send messages from one account to the other without using the transport bridge. It would be interesting to analyze if it would be possible and beneficial for the transport to offer this directly.
Where queues are currently just a name, I would imagine that the transport would need to be smart enough to recognize the difference between just a name, which must be a local queue, and something like a full queue ARN that would allow sending to a different account if IAM permissions were set appropriately.
I would also imagine headers would have to be added or modified so that reply messages could be properly routed, and so that failed messages processed by a centralized ServiceControl instance could be replayed to the correct account as well.
Analysis would also need to include whether there are security risks inherent in transmitting a full queue ARN which includes information like the account number, and what could be done to mitigate those risks.
The text was updated successfully, but these errors were encountered: