我在我的服务器上使用文本到语音合成平台(可能用Java编写)。
虽然上述应用程序在我的服务器上运行,但用户可以使用嵌入式HTML <audio>
标记将音频作为wav文件的URL获取,如下所示:
<audio controls>
<source src=”http://myserver.com:59125/process?INPUT_TEXT=Hello%20world” type=”audio/wav”>
</audio>
在上面的“ src ”属性中,“进程”使用本地端口59125请求合成某些文本。
我担心的是,我可能会开始看到性能问题和内存不足错误,这会导致TTS综合平台服务器(但不是网站)每隔几天就会崩溃,显然是由一个或多个滥用它的实体触发的他们自己的应用程序的Web服务。
我希望保护网址请求,以便第三方无法将我的文字转语音服务器用于与我的网站无关的音频剪辑。
如何保护网址服务?
答案 0 :(得分:1)
这取决于您使用的服务器。可能的方法是:
Apache中的IP白名单示例:
Deny from all
# server himself
Allow from 127.0.0.1
Allow from 192.168.1.14 # maybe some additional internal network IP
Allow from 192.168.1.36 # or another machine in the local network
Allow from 93.184.216.34 # or some machine somewhere else on the web
答案 1 :(得分:1)
您最好的选择是使用上述来自feeela的答案将TTS平台的使用限制在所述网络服务器上(这将是用户请求音频以及应该在何处实施安全逻辑的地方)
之后你需要编写一个“代理”脚本,该脚本从你选择的逻辑/方法托管音频标签的页面中即时生成令牌,并检查其有效性(你可以使用会话) /其他用户数据和盐),如果有效,它应该调用TTS引擎并返回音频,否则生成错误/重定向/无论你想要什么
答案 2 :(得分:1)
我认为此网址嵌入在 public 网站中,因此任何随机 public 用户都需要能够访问此网址才能下载该文件。这使得几乎不可能像那样保护。
最大的问题是你公开展示了一个有用的服务,任何人都可以使用它做有用的事情。即,只要通过请求我构建的URL,我就可以让您的服务器为我做有用的工作(将我的文本转换为语音)。这里的核心问题是输入文本可由最终用户完全配置。
为了消除任何随机人员使用您的服务器的任何动机,您需要取消任何人转换任何随机文本的能力。如果您是唯一想要负责输入文本的人,则必须将输入列入白名单并验证输入,或使用ID识别输入。例如,而不是
http://myserver.com:59125/process?INPUT_TEXT=Hello%20world
您的网址看起来更像:
http://myserver.com:59125/process?input_id=42
42
已替换为服务器上的Hello world
。将无法提供未知的ID。
或者,再次验证并列入白名单:
GET http://myserver.com:59125/process?INPUT_TEXT=Foo%20bar
404 Not Found
Speech for "Foo bar" does not exist.
无论采用哪种方法,您都需要在中间使用某种代理,而不是直接将TTS引擎暴露给全世界。此代理还可以缓存生成的文件,以避免反复重复转换相同的输入。
最终结果将如下:
GET http://myserver.com/tts?input=Hello%20world
myserver.com
验证输入,返回403或404表示无效输入myserver.com
代理localhost:59125?INPUT_TEXT=Hello%20World
的请求(如果尚未缓存)myserver.com
缓存结果myserver.com
提供结果这可以使用任意数量的不同Web服务器和/或CGI程序以任意数量的方式完成,这些程序执行必要的步骤2和可能的3步。
答案 3 :(得分:1)
这取决于你的意思&#34;保护它&#34;。
也许您希望某些用户只能访问它?在这种情况下,您可以轻松地回答:向每个用户发出他们访问网站时需要输入的登录凭据,并将这些凭据传递给API。没有有效凭据的任何人都将无法使用该API。完成工作。
或许您希望它适用于任何人,但只能用于特定网站?这更加困难,因为您拥有的任何类型的身份验证密钥都需要位于网站的Javascript代码中,因此对于想要复制它的人来说是可见的。这不是一个万无一失的解决方案,但我建议的最佳解决方案是将每个API密钥链接到拥有它的站点的URL。然后使用HTTP referrer标头检查是否正在从正确的站点调用使用给定API密钥进行的调用。 HTTP请求可能是欺骗性的,包括引用者标题,所以这不是万无一失的,但是可以防止大多数未经授权的使用 - 有人必须走很远的距离才能绕过它(他们会这样做)可能必须设置一个转发API请求并欺骗标头的代理服务器。除非你的API是一个非常有价值的资产,否则不大可能发生这种情况,但是如果你担心这一点,那么你可以通过频繁和随机地更改API密钥来使它们变得更难。
但无论你做什么,你需要做的第一件事就是切换到HTTPS而不是HTTP。