您何时会在命名空间上使用子域?即http://admin.foo.com VS http://foo.com/admin
或者,我也喜欢 api.foo.com 与 foo.com/api 的外观。我还发现,设置子域有点棘手。
您何时会在命名空间上使用子域?即http://admin.foo.com VS http://foo.com/admin
或者,我也喜欢 api.foo.com 与 foo.com/api 的外观。我还发现,设置子域有点棘手。
在文件夹或子域中安装另一个应用程序对 Web 服务器来说没什么大不了的,但是如果您的 Rails 应用程序包含 /admin 和普通应用程序,那么将一个应用程序用作子域会变得更加棘手。
值得庆幸的是,Rails 路由器在这方面非常灵活,并且很好地支持了这两种情况。
TLDR:Rails 通过路由引擎支持两种方式,在这一点上它归结为个人喜好(尽管我怀疑子域选项不会与路径助手配合得很好)
/admin 路线
为了实现/admin
路由,Rails 在路由中支持命名空间的概念。因此,在 Rails 应用程序中有一个 /admin 区域,您只需routes.rb
像这样写:
namespace :admin do
resources :users
resources :posts
end
然后,您将 /admin 区域的控制器放在 controllers/admin/.rb 中,并且该类必须以 Admin 为前缀(如Admin::PostsController
)。
由于大多数应用程序的管理区域很可能会与普通应用程序中的模型进行交互,因此可以肯定地说进行命名空间是最方便的方式。
子域路由
但命名空间也可以与子域一起使用,事实证明:
Rails 路由器可以定义constraint
块并在这些块内定义命名空间。因此,如果您只想在 admin.example.com 子域中托管上面的命名空间,您可以这样做:
constraints(:subdomain => /admin/) do
namespace :admin do
resources :users
resources :posts
end
end
(我不知道约束功能,但这篇博文似乎解释得很好)
这显然需要您配置 Web 服务器,以便将 admin.example.com 和 www.example.com 提供给同一个 Rails 应用程序。
我不确定会话(通过 cookie 实现)是否被延续,但我想你可以解决这个问题。
我认为另一个答案解决了实用性问题,但纯粹是从安全角度来看:
Rails 安全指南建议将 admin 放在子域中,因为它更能抵御 XSS 攻击:
将管理界面放到一个特殊的子域,例如 admin.application.com 并使其成为一个单独的应用程序,并拥有自己的用户管理。这使得从通常的域 www.application.com 窃取管理 cookie 是不可能的。这是因为您的浏览器中的相同来源策略:www.application.com 上的注入 (XSS) 脚本可能无法读取 admin.application.com 的 cookie,反之亦然。
因此,从安全角度来看,将 admin 放在子域中可能更安全。