Support for applications requesting an API key from OctoPrint has recently landed to the Maintenance branch, which is awesome; no more finding and copy/pasting a long string of characters with the chance of missing one and things not working.
I have implemented an initial version in the Cura OctoPrintPlugin, and this is what it looks like:
I have two suggestions, from the perspective of the "client" (Cura in this case).
As far as I have been able to tell, there is no official way to query OctoPrint if requesting an AppKey is supported by an OctoPrint instance. The version may be too old, or the plugin may have been disabled. It would be nice to be able to query this, so the client can only show the button to request access to an OctoPrint instance directly if it supports this. I could just start the request and see the response, but that already opens up the dialog Access Request dialog in any running OctoPrint interfaces, so I would prefer not to start the request unless the user actively presses a button.
I have found a hacky way, which is to do a
GET request to
/plugin/appkeys/request (without an
app_token). This results in a
405 Method Not Allowed http error if the plugin is available (because it expects a POST request), which does not initiate a dialog. It would be nicer if I could GET something (
/plugin/appkeys/request) that returns a
204 No Content or similar.
The second issue is that it can easily happen that many Access Requested dialogs are spawned that are actually orphans. If there are multiple octoprint pages open (in different tabs or different browsers), they can all get the dialog but if one of those them makes the "Allow" decision, all of the other dialogs become irrelevant (but stick around). Also if the originating application is closed down before the decision is made, the dialog also stays open even though the decision has become irrelevant.
My original implementation already had a way to close orphan dialogs, would you like me to create a PR to backport this mechanism, or was there a specific reason you did not want to handle orphan dialogs the way I did it?
PS: if you would prefer this on github, then I'll move the discussion there. But I figured it was more a discussion than a bug or feature request, and everybody likes to see a cool video, right?