如果您只从自己的开发机器设置数据,请考虑使用 Admin SDK。此 SDK 以管理权限访问后端,因此它绕过了安全规则。这意味着您可以拥有以下规则:
{
"rules": {
".read": true,
".write": false
}
}
当我创建一个应用程序管理页面(通常是一个简单的 StackBlitz 或 JSBin)时,即使在匿名用户登录之前,我通常会做的第一步是匿名登录,记录我的 UID,然后只授予写入权限到我的 UID。
在看起来像这样的规则中:
{
"rules": {
".read": true,
".write": "auth.uid === 'myUid'"
}
}
稍后,如果我扩展用户登录(即使再次仅针对其他管理员),我会将其扩展为更详细的检查,例如:
{
"rules": {
".read": true,
".write": "auth.uid === 'myUid' ||
(auth.token.email_verified == true &&
auth.token.email.matches(/.*@google.com$/))"
}
}
使用上述所有规则,您仍然会收到有关用户读取整个数据库能力的警告。顶级".read": true 的主要问题是它允许使用单个HTTP GET 抓取您的网站到https://yourproject.firebaseio.com/.json。有相当多的脚本使用它来查找用户信息
如果这对您的应用不是问题,您可以在此时禁用警报。
如果是问题,您可以考虑通过在规则中编码访问模式来保护数据。
例如,如果您有一个包含所有游戏列表的顶级节点,然后有另一个包含每个游戏移动的顶级节点,您可以将读取权限下推到这些级别:
{
"rules": {
"games": {
".read": true,
},
"moves": {
"$gameid": {
".read": true
}
}
}
}
这种结构,任何人都可以阅读完整的游戏列表。但当时只能阅读一场比赛的动作。这与您首先看到游戏列表,然后看到您选择的游戏的移动的应用程序相匹配。
使用这些规则,用户仍然可以访问所有数据,但前提是他们遵守您的应用程序的规则。而且(也许更重要的是)公然的顶级 https://yourproject.firebaseio.com/.json 访问权限将不再起作用。