这里有初学者问题。我想构建一个应用程序，它将成为70个单位连锁餐厅的内联网。我需要的是每个实体餐厅位置都可以看到发布到MongoDB数据库的数据，并显示在商店的页面上，挂在墙上的屏幕上。这些数据将特定于每个位置，例如公告，需要由该商店填写的餐饮订单等等...我的问题是，如何创建路线以便每个商店只能看到他们的数据而无需创建70种不同的路由或使用身份验证来使用用户ID？
尝试避免用户登录并且：
“/商店1” “/商店2” “/ store3” 等...
似乎我可以查询网站ID或类似的东西
希望这可以做到。
答案 0 :(得分：0)
如果您正在谈论所有70家餐馆都可以访问的中央服务器，并且您希望所有人都拥有相同的路由，那么您需要从请求中解读其他一些线索，以确定它是哪个餐厅正在提出请求。
由于您已经进行了身份验证，我将假设此处没有任何安全问题 - 这是在Intranet上，只有餐馆员工才能访问。
因此，以下是您可以从任何特定请求中获得的线索，以决定显示哪家餐厅的数据：
以下是每个选项的更多信息：
<强>曲奇
在此实施中，如果客户到达时没有为餐馆ID设置cookie，那么您将他们带到一个开始页面，在那里他们选择他们想要查看数据的餐馆，并要求用户手动选择所需的餐厅。然后，您在该浏览器中设置一个持久的cookie，从那时起（只要不删除cookie），您的服务器可以默认只为他们的餐厅显示它们。
查询参数
在此实现中，您使用cookie选项中的一些初始餐馆规范，然后生成页面，其中所有链接都在其中指定了列出餐馆ID的查询参数（可能使用模板系统）。现在，这通常不受普通cookie系统的青睐。
IP地址
如果您所有的餐馆都有自己的子网（可能是通过某种私人连接连接到中央服务器的某种宽带连接，那么您可以建立一个餐馆源IP地址的小表，以便您可以识别哪个餐厅完全根据请求的IP地址提出请求。根据您的网络拓扑结构，这可能是可行的，也可能是不可行的。这比任何其他选项都要自动化。
单独的子域
这有点像基于cookie的选项，但不是设置cookie，一旦选择了所需的餐厅，您将重定向到特定于该餐厅的子域。所有子域仍将指向同一主机，但主机可以从发出请求的子域中识别所需的餐馆。与查询参数选项类似，您在服务器端使用一些模板系统来重写所有链接以包含正确的子域，这样您就可以在导航时保持在同一个子域中。
在所有这些选项中，IP地址方案是唯一一个完全自动化的方案，但根据您的网络拓扑结构可能会也可能不可行。在其他选择中，cookie是最直接的实现，因为页面链接本身不必重写。
企业配置
在您“管理”任何批准使用的浏览器的企业场景中，您还可以预先配置每个餐厅的浏览器，以自动提供一些标识（自定义标题或cookie）和您的服务器可以使用该标识信息来确定哪个餐厅正在做出选择。这只需要通过预先配置和批准且维护得当的浏览器访问您的网站（这可能比它的价值更加痛苦）。
例如，here's how you would configure a custom header on all requests with Microsoft Edge。