[
https://issues.apache.org/jira/browse/FLINK-16920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Lonergan updated FLINK-16920:
----------------------------------
Description:
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.
was:
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.
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.
> 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)
