Search before asking
I searched existing issues for AlertPluginInstanceController permission and alert plugin instance permission and did not find a similar report.
What happened
On the current dev branch, several alert plugin instance APIs do not enforce the alert plugin instance permission consistently.
Code paths observed at commit cd8abbaa626d1b7da229fc6883cbb80b687428d6:
GET /alert-plugin-instances/list calls AlertPluginInstanceService.queryAll() without passing loginUser.
GET /alert-plugin-instances/verify-name calls AlertPluginInstanceService.checkExistPluginInstanceName(...) without any permission check.
GET /alert-plugin-instances calls AlertPluginInstanceService.listPaging(loginUser, ...), but the implementation ignores loginUser and queries all matching alert plugin instances.
In AlertPluginInstanceServiceImpl, create, updateById, deleteById, and getById call canOperatorPermissions(...) with AuthorizationType.ALERT_PLUGIN_INSTANCE, but queryAll, checkExistPluginInstanceName, and listPaging do not perform permission checks or resource filtering.
This is inconsistent with nearby APIs such as AlertGroupServiceImpl, where list/query methods filter non-admin users by authorized resource ids before returning data.
What you expected to happen
Alert plugin instance query and validation APIs should enforce permissions consistently.
Users without alert plugin instance view/manage permission should not be able to list all alert plugin instances or infer instance names through the verify-name endpoint. Depending on the intended authorization model, these APIs should either return USER_NO_OPERATION_PERM or only return resources the current user is authorized to view.
How to reproduce
- Use the current
dev branch.
- Create or use a non-admin user that does not have alert plugin instance view/manage permission.
- Call the following APIs:
GET /dolphinscheduler/alert-plugin-instances
GET /dolphinscheduler/alert-plugin-instances/list
GET /dolphinscheduler/alert-plugin-instances/verify-name?alertInstanceName=<name>
- Observe that these code paths are served by unfiltered mapper queries or name-existence checks instead of permission denial or authorized-resource filtering.
Anything else
Relevant files:
dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/controller/AlertPluginInstanceController.java
dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/AlertPluginInstanceServiceImpl.java
dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/AlertGroupServiceImpl.java
A fix should probably add permission checks or authorized-resource filtering to queryAll, checkExistPluginInstanceName, and listPaging, plus tests for unauthorized users.
Version
dev
Search before asking
I searched existing issues for
AlertPluginInstanceController permissionandalert plugin instance permissionand did not find a similar report.What happened
On the current
devbranch, several alert plugin instance APIs do not enforce the alert plugin instance permission consistently.Code paths observed at commit
cd8abbaa626d1b7da229fc6883cbb80b687428d6:GET /alert-plugin-instances/listcallsAlertPluginInstanceService.queryAll()without passingloginUser.GET /alert-plugin-instances/verify-namecallsAlertPluginInstanceService.checkExistPluginInstanceName(...)without any permission check.GET /alert-plugin-instancescallsAlertPluginInstanceService.listPaging(loginUser, ...), but the implementation ignoresloginUserand queries all matching alert plugin instances.In
AlertPluginInstanceServiceImpl,create,updateById,deleteById, andgetByIdcallcanOperatorPermissions(...)withAuthorizationType.ALERT_PLUGIN_INSTANCE, butqueryAll,checkExistPluginInstanceName, andlistPagingdo not perform permission checks or resource filtering.This is inconsistent with nearby APIs such as
AlertGroupServiceImpl, where list/query methods filter non-admin users by authorized resource ids before returning data.What you expected to happen
Alert plugin instance query and validation APIs should enforce permissions consistently.
Users without alert plugin instance view/manage permission should not be able to list all alert plugin instances or infer instance names through the verify-name endpoint. Depending on the intended authorization model, these APIs should either return
USER_NO_OPERATION_PERMor only return resources the current user is authorized to view.How to reproduce
devbranch.GET /dolphinscheduler/alert-plugin-instancesGET /dolphinscheduler/alert-plugin-instances/listGET /dolphinscheduler/alert-plugin-instances/verify-name?alertInstanceName=<name>Anything else
Relevant files:
dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/controller/AlertPluginInstanceController.javadolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/AlertPluginInstanceServiceImpl.javadolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/AlertGroupServiceImpl.javaA fix should probably add permission checks or authorized-resource filtering to
queryAll,checkExistPluginInstanceName, andlistPaging, plus tests for unauthorized users.Version
dev