sendgrid：尝试与API添加范围时的错误
我正在尝试使用API添加范围（实际上是我用来连接到API的相同键）。 我正在关注 doc ，我当前的范围确实包括api_key_update许可。
但是，当我尝试在API密钥中添加更多范围时，我总是会收到400不良请求错误。
例如，显然这是设置“ API键”许可以在管理面板中“完整访问”时的最小范围（通过get v3/scopes api Endpoint检索
templates.read
api_keys.create
api_keys.read
api_keys.update
api_keys.delete
sender_verification_eligible
2fa_required
）现在，尝试在其中添加mail.send范围，我收到此错误消息：
{“ errors”：[{“ field”：null，“ message”：“未经授权的范围：[[邮件
。我还可以通过将它们排除在传递的数组中，可以成功删除范围。但是，无论我尝试添加哪个范围，我都无法添加它们。
我已经使用node.js和卷发进行了测试，以下是卷曲测试脚本：
Working:
curl -X PUT --header "Authorization: Bearer INSERT_API_KEY" --header "Content-Type: application/json" --data '{"name": "INSERT_API_KEY_NAME", "scopes": ["templates.read", "api_keys.create", "api_keys.read", "api_keys.update", "api_keys.delete", "sender_verification_eligible", "2fa_required"]}' https://api.sendgrid.com/v3/api_keys/INSERT_API_KEY_ID
Not working:
curl -X PUT --header "Authorization: Bearer INSERT_API_KEY" --header "Content-Type: application/json" --data '{"name": "INSERT_API_KEY_NAME", "scopes": ["templates.read", "api_keys.create", "api_keys.read", "api_keys.update", "api_keys.delete", "sender_verification_eligible", "2fa_required", "mail.send"]}' https://api.sendgrid.com/v3/api_keys/INSERT_API_KEY_ID
I'm trying to add scopes to an API key with the API (actually to the same key I'm using to connect to the API).
I'm following the example in the doc, and my current scopes do include the api_key_update permission.
However when I try to add more scopes to the API key, I always receive a 400 Bad Request error.
For example apparently this is the bare minimum of scopes when having set the "API Keys" permission to "Full Access" in the admin panel (retrieved via the GET v3/scopes API endpoint):
templates.read
api_keys.create
api_keys.read
api_keys.update
api_keys.delete
sender_verification_eligible
2fa_required
And when I now try to add a mail.send scope to it, I receive this error message:
{"errors":[{"field":null,"message":"unauthorized scopes: [mail.send]"}]}
When I just pass the already existing scopes, I receive a successful response. I can also remove scopes successfully by leaving them out of the passed array. But I cannot add them, no matter which scope I try to add.
I've tested with Node.JS and with curl, here are the curl test scripts:
Working:
curl -X PUT --header "Authorization: Bearer INSERT_API_KEY" --header "Content-Type: application/json" --data '{"name": "INSERT_API_KEY_NAME", "scopes": ["templates.read", "api_keys.create", "api_keys.read", "api_keys.update", "api_keys.delete", "sender_verification_eligible", "2fa_required"]}' https://api.sendgrid.com/v3/api_keys/INSERT_API_KEY_ID
Not working:
curl -X PUT --header "Authorization: Bearer INSERT_API_KEY" --header "Content-Type: application/json" --data '{"name": "INSERT_API_KEY_NAME", "scopes": ["templates.read", "api_keys.create", "api_keys.read", "api_keys.update", "api_keys.delete", "sender_verification_eligible", "2fa_required", "mail.send"]}' https://api.sendgrid.com/v3/api_keys/INSERT_API_KEY_ID
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我到了底部。
有权更新其他API密钥的API键只能给出API密钥本身具有的权限。这就是为什么具有完整访问权限的API键能够更新另一个API键的范围，但是您的API键只有少数权限，包括访问更新其他API键，无法添加其他范围。这也得出了一个结论，即API密钥也不能为自己提供进一步的权限。
这对于有限的范围API键是有意义的。极限背后的意图是，如果仅执行某些操作，则可以限制泄漏API键的潜在损害。如果您泄漏了一个钥匙，并且能够将权限添加到自身中，则将使有限的许可功能变得毫无用处。
我们接受文档中的情况并不清楚，我们已经提出了一个问题来更新文档，因此这更明显。
I got to the bottom of this.
An API Key with permission to update other API keys can only give permissions that the API Key itself has. That's why an API key with full access was able to update the scopes on another API Key, but your API Key with only a few permissions including access to update other API keys couldn't add other scopes. This also leads to the conclusion that an API key cannot give itself further permissions too.
This makes sense for limited scope API keys. The intention behind the limits are that you can limit the potential damage from leaking an API key if it can only perform certain actions. If you leaked a key and it was able to add permissions to itself, that would render the limited permission feature useless.
We accept that this isn't clear in the documentation and we have raised an issue to update the documentation so this is more obvious.