[
https://issues.apache.org/jira/browse/FLINK-16920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072672#comment-17072672
]
Chesnay Schepler commented on FLINK-16920:
------------------------------------------
The yarn commands not being documented is a bug (FLINK-13305).
This command uses GET since the YARN proxy doesn't support other methods
(YARN-2031).
We always use yarn-cancel since the UI doesn't know how the cluster is
deployed. This technically could be fixed for non-YARN cases, but this wouldn't
address the problem at it's core.
Disabling the cancel REST endpoint would imply that jobs cannot be canceled in
any way, neither through the WebUI nor client (since it goes through the REST
API).
This is likely not quite what you desire.
However, just disabling the cancel button doesn't really provide any guarantees
as outlined in FLINK-14393.
There have also been some thoughts on more fine-grained access control in
FLINK-10497.
Overall, we are aware of the problem, but it is a bit tricky and we haven't
come up with a good solution yet.
> Flink UI cancel uses an undocumented rest api and uses GET rather than a
> mutating HTTP method
> ---------------------------------------------------------------------------------------------
>
> Key: FLINK-16920
> URL: https://issues.apache.org/jira/browse/FLINK-16920
> Project: Flink
> Issue Type: Bug
> Components: Runtime / Web Frontend
> Affects Versions: 1.10.0
> Reporter: John Lonergan
> Priority: Minor
>
> We were trying to build proxy that excluded all mutating operations and the
> documented rest API indicates that all mutating ops are always PUT/POST/PATCH
> etc and never GET.
> However, then we took a look at the "cancel" feature in the UI and it uses an
> undocumented API that violates good REST practice by mutating on a GET.
> The UI contains this comment ....
> https://github.com/apache/flink/blob/eb489cc2f7e01fa43cae1bf2106fc30f0cf829fb/flink-runtime-web/web-dashboard/src/app/services/job.service.ts#L75
> ```
> /**
> * Uses the non REST-compliant GET yarn-cancel handler which is available
> in addition to the
> * proper BASE_URL + "jobs/" + jobid + "?mode=cancel"
> * @param jobId
> */
> cancelJob(jobId: string) {
> return this.httpClient.get(`${BASE_URL}/jobs/${jobId}/yarn-cancel`);
> }
> ```
> Why is this bending necessary?
> Why not use a POST or other mutating method?
> Why not use a documented API?
> This kind of thing makes it difficult to trust the product and makes it
> difficult to build a secure deployment.
> Any ideas?
> ==
> Suggestion ...
> There exists "web.submit.enabled" to turn off /jar features
> What would also be useful is "web.cancel.enabled" to turn off the UI button
> and also the servicve endpoint.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
