-
由 Nick Malcolm 创作于
In the original commit, anyone in possession of a token could attempt to revoke it. Now, the caller (current_user) must be a Group Owner to attempt to revoke a token. Rate limiting is removed as we can now rely on the regular rate limits. A malicious group owner can't add a random user and feasibly attempt to brute-force their PersonalAccessToken. Nor can they find a leaked token and brute-force a number of groups to try and revoke it against a random one. We can assume that a malicious actor with a token could use another API endpoint if they wanted to (e.g. /user) to read information, update records, or otherwise cause havoc. So the next threat is a well-intentioned person trying to "help" when they find a leaked token. A GitLab EM & maintainer both felt that the risk of breaking an organization's systems by revoking a token was too great and, therefore, revocation should only be possible if the caller is a Group owner.
由 Nick Malcolm 创作于In the original commit, anyone in possession of a token could attempt to revoke it. Now, the caller (current_user) must be a Group Owner to attempt to revoke a token. Rate limiting is removed as we can now rely on the regular rate limits. A malicious group owner can't add a random user and feasibly attempt to brute-force their PersonalAccessToken. Nor can they find a leaked token and brute-force a number of groups to try and revoke it against a random one. We can assume that a malicious actor with a token could use another API endpoint if they wanted to (e.g. /user) to read information, update records, or otherwise cause havoc. So the next threat is a well-intentioned person trying to "help" when they find a leaked token. A GitLab EM & maintainer both felt that the risk of breaking an organization's systems by revoking a token was too great and, therefore, revocation should only be possible if the caller is a Group owner.
代码所有者
将用户和群组指定为特定文件更改的核准人。 了解更多。