假设appengine上有两个不同的应用程序 - 一个由Go驱动，另一个由PHP提供
他们每个人都需要能够完全通过后端网络向彼此发出特定请求（即这些是仅服务需要发出这些特定请求 - 其他远程请求应该被阻止）
这样做的最佳做法是什么？在我的头顶，这里有3个可能的解决方案，为什么我有点担心他们
1）不要将它们作为单独的应用程序，而是模块
问题在于使用模块会引入一些其他烦恼 - 例如Channel Presence报告的困难。另外，从概念上讲，这2个请求实际上是他们触摸的唯一地方，如果它们是分开的，那么在数据库使用等方面会发现什么是更清楚的。但存在问题更多的是一个显示阻碍
2）使用一些硬编码的长密钥附加请求，并且只允许通过SSL进行响应
依赖于此似乎有点奇怪，因为密钥永远不会改变......理论上，唯一可以知道的方法是帐户管理员或有消息来源的人透露它...但我不知道不知道，只是看起来很奇怪
3）仅允许通过某些IP范围（可能与＃2结合）
这似乎是不确定的，IP范围是否可以明确知道？
4）Pub / Sub
所以似乎AppEngine允许发布/发布机制 - 但这并不适合我的用例，因为我想立即得到响应 - 一旦订阅者处理它就不会通过回发
所有 - 作为一个侧面点，假设它是某种https请求，这是使用每种语言的Socket API完成的吗？
答案 0 :(得分：2)
HTTPS通常是一个很好的主意（不仅仅是两个GAE应用程序之间的通信）。
但是，对于特定用例，我建议依赖X-Appengine-Inbound-Appid请求标头：App Engine的基础架构可确保无法在来自GAE应用程序的而非请求中设置此项，并且，对于做来自GAE应用程序的请求（通过不遵循重定向的url-fetch），标头设置为app-id。
对于https://cloud.google.com/appengine/docs/go/urlfetch/的Go，以及https://cloud.google.com/appengine/docs/php/urlfetch/的PHP，记录了这一点（顺便说一下，对于Java和Python来说，它也是一样的。）
答案 1 :(得分：1)
- 纯粹在后端网络上
- 仅允许通过某些IP范围
使用app引擎基础架构很难实现这些要求，因为您无法控制物理网络路由。来自应用引擎FAQ：
App Engine目前不提供将静态IP地址映射到应用程序的方法。为了优化最终用户和App Engine应用程序之间的网络路径，不同ISP或地理位置的最终用户可能使用不同的IP地址来访问相同的App Engine应用程序。
因此，总是假设您的通信是在开放网络上进行的，并且从不假设有关IP的任何内容。
使用一些硬编码的长密钥
附加请求
硬编码长秘密不提供任何额外的安全性，仅obscurity。
仅允许通过SSL进行响应
这是一个更好的主意;使用强大的算法加密内部流量的全部。例如，ECDHE-RSA或ECDHE-ECDSA（如果有）。