以下代码 sn-p 是我在 Sinatra 应用程序中处理路由的方式。我的所有视图都包含在我的视图/页面目录中。这些只是代表静态html的haml文件，带有一些javascript。以这种方式加载视图是否有任何负面影响？如果页面不存在，则会引发文件未找到错误。我担心这在某种程度上是一种攻击媒介。
error RuntimeError do
status 500
"A RuntimeError occured"
end
get '/:page' do
begin
haml "pages/#{params['page']}".to_sym
rescue Errno::ENOENT
status 404
"404"
end
end
【问题讨论】：
我不确定这是否是一个安全问题（我对 Sinatra 的所有细节并不了解），但在使用用户指定的数据（例如您的示例中的 params['page']）时，我倾向于偏执。如前所述，我不确定 Sinatra 是否会清理内容并使这个例子变得不可能，但想象一下它说的是 ../db_connection.yml。因此，Sinatra 会被告知加载可能实际存在的 haml 文件 pages/../db_connection.yml，并将其显示给用户，向他们展示您的数据库配置。
如果您的pages 目录中没有任何奇怪的符号链接，那么将所有重复出现的点替换为传递字符串的.gsub(/\.+/, ".") 之类的东西就足够了（或者如果您没有，则替换所有点'不需要他们在名字中更加偏执）。我不确定是否存在任何多字节的不安全性，尽管有人可以用编码做一些丑陋的事情，并且进行替换可能根本没有用，因为漏洞利用仍然可以工作。
编辑：对 Sinatra 手册的简短阅读得到了这一点
顺便说一句，除非您禁用路径遍历攻击保护（见下文），否则请求路径可能会在匹配您的路由之前被修改。
因此，似乎只使用 params 值而不进行任何特殊过滤应该是安全的，但是您可能希望更多地查看文档（尤其是安全部分）。但是，如果可以确定 pages 目录中的文件是否存在，我认为这不是太大的安全问题。
【讨论】：
以这种方式加载视图是否有任何负面影响？
时间就是一分钟，生成一个页面比提供一个静态页面需要更长的时间。出于同样的原因，资源使用将是另一个问题。又增加了复杂性。重新发明轮子是另一回事。
为什么不只使用put static pages in the public directory? 或者为什么不使用static site generator?
选择适合您需求的工具，不要重新发明轮子（尤其是当框架已经为您提供了那个轮子时！）
【讨论】：