ruanwenjun opened a new issue, #18299: URL: https://github.com/apache/dolphinscheduler/issues/18299
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/dolphinscheduler/issues?q=is%3Aissue) and found no similar issues. ### What happened The access token service does not consistently enforce that a non-admin user can only create or update access tokens for the current login user. In the current API service implementation, `createToken` allows a request-supplied `userId` when the access-token operation permission check succeeds, and the access-token permission check is permissive for ordinary users. `updateToken` checks ownership of the existing token, but then accepts the request-supplied `userId` and can move the token to another user. This appears to regress the ownership boundary previously fixed by #11031 / #11032: access tokens should only be usable by their creator unless the operator is an administrator. ### What you expected to happen For non-admin users: - creating an access token with `userId` different from the current login user should be rejected; - updating an existing own access token to a different `userId` should be rejected; - access token operation permissions should not bypass this ownership rule. Administrators should still be able to manage tokens for other users if that remains the intended behavior. ### How to reproduce Add focused service tests around `AccessTokenServiceImpl`: 1. Use a non-admin login user. 2. Try to create an access token for a different `userId`. 3. Try to update the login user's existing token while passing a different `userId`. 4. Both operations should fail with no-operation permission, but the current implementation allows these paths when the access-token operation check returns true. ### Anything else The relevant code path is `AccessTokenServiceImpl#createToken`, `AccessTokenServiceImpl#updateToken`, and `ResourcePermissionCheckServiceImpl.AccessTokenResourcePermissionCheck`. ### Version dev ### Are you willing to submit PR? - [X] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
