Open danielmarbach opened 8 years ago
I imagine organization with strict security policies would freak out that something is listening for network traffic for no good reason.
Can we include a header in the message that would instruct the receiving end that Reply is not supported on this message because the sender is a "send only" gateway?
@MarcinHoppe I think we can implement whatever is necessary to support it, IF we think we should support it.
@danielmarbach @MarcinHoppe I can very clearly understand this case. If there is no need to open network connections then why make it run?
Maybe we can address this by improving our guidance and samples? Add a sample that at least does something with authentication and maybe setup ACL's on the connection? We could also mention something like firewall and port forwarding, DMZ's and network load balancers?
Maybe we should do both?
@danielmarbach @ramonsmits What would be the guidance we could give to the user in this case?
I was also thinking about providing a workaround and the only thing I can think of off the top of my head is closing the listening port on the firewall in front of he sending endpoint. It does the trick but still wastes resources and makes the networking setup so much more involved.
Google Group Discussion
So the basic idea is that the user would like to have a "send only" gateway where the site which is doing
SendToSites
only acts as an HTTP client and doesn't expose an incoming channel.The implications of supporting that is that it would break Request/Reply semantics over the gateway. Are we willing to introduce this as a configuration option on the gateway and deal with the unpleasant surprises when someone is using Reply but the message never arrives?
My opinion is No but I would like to discuss it here.