admin应该是子域还是命名空间？

Question

您何时在命名空间上使用子域？即http://admin.foo.com VS http://foo.com/admin

或者,我也喜欢api.foo.com看起来像VS foo.com/api.我也发现,子域设置有点棘手.

Answer 1

在文件夹或子域中安装另一个应用程序与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

(我不知道约束功能,但这篇博文似乎很好地解释了它)

这显然要求您以将admin.example.com和www.example.com提供给同一Rails应用程序的方式配置Web服务器.

我不确定会话(通过cookie实现)是否结转,但我想你可以解决这个问题.

Answer 2

我认为另一个答案解决了实用性问题，但纯粹是从安全性的角度：

《Rails安全指南》中建议将admin放在子域中，因为它与XSS攻击更加隔离：

将管理界面放置到特殊的子域（例如admin.application.com），并使其成为具有自己的用户管理的独立应用程序。这样就不可能从通常的域名www.application.com窃取管理员cookie。这是由于浏览器中的原始策略相同：www.application.com上的注入（XSS）脚本可能无法读取admin.application.com的cookie，反之亦然。

因此，从安全角度来看，将admin放在子域中可能更安全。