3 ms·
This might be an intentional interpretation of the plugin authors. Meaning they potentially took the reasoning "in order to prevent destruction actions" to inv
by tharkun__ 3y ago
This might be an intentional interpretation of the plugin authors.
Meaning they potentially took the reasoning "in order to prevent destruction actions" to inversely mean that non-destructive POST requests must be OK then and do not require a prompt. Plenty of POST search APIs out there to get around path length limitations and such.
That is probably not the intended meaning but a valid enough if kind of tongue in cheek-we-will-do-as-we-please-following-the-letter-only implementation. And like the author found even creative a d not destructive actions can be surprising and unwanted. But isn't this what AI would ultimately be about?
- fieldcny 3y agoWhy would it not be the intended meaning, if they wanted it to be all post requests they would have said so, the specifically scoped it “destructive actions”, their intention is in their words. POST as a verb can pretty much be used for anything retrieval, creation, deletion, updates, noops , it’s just code it does whatever we tell it to do.
- kevincox 3y agoI think you are slightly misreading it. The rule is a requirement and an explanation. Requirement: for POST requests, we require that developers build a user confirmation flow Explanation: to avoid destruction actions I think you are reading it as if it said: > for POST requests, we require that developers build a user confirmation flow *for* destruction actions