Hi all,
I had made some contributions to the device code authentication with PKCE in the past and we have used it as our main authentication procedure, which works under normal circumstances (local client) perfectly fine.
Recently, we have setup up a Jupyter notebook with an R Kernel on a remote server. That's where the problem begins. The Jupyter environment is regarded as an interactive session rlang::is_interactive() and httr2 tries to open up the internet browser that is defined in Rs global environment. Unfortunetly the user never gets to see the browser, because it gets executed on the remote machine. And usually you would expect that the URL and the code is printed to console in order to open the browser on your local machine, as it is already defined here.
Our workaround for this in the Jupyter notebook would be to run the authentication in a temporary non-interactive state with rlang::with_interactive({...}, value=FALSE). This way we keep the general interactiveness of Jupyter and disable it once during authentication. So far, so good.
Now, there is still a big issue with this approach. This line is blocking this non-interactive state. As I understand, the intention for oauth_flow_check(...,interactive=TRUE) is a legacy thing, that is was assumed that the user needs to be actively involved by direct interaction with the browser. To cut it short, this line throws an error, because this "interactive state" is required and prevents the printing of the URL and the code from ever being called.
My question is whether the oauth_flow_check is really required here or the default value for interactive could be changed to rlang::is_interactive()?
Best regards,
Florian
Hi all,
I had made some contributions to the device code authentication with PKCE in the past and we have used it as our main authentication procedure, which works under normal circumstances (local client) perfectly fine.
Recently, we have setup up a Jupyter notebook with an R Kernel on a remote server. That's where the problem begins. The Jupyter environment is regarded as an interactive session
rlang::is_interactive()and httr2 tries to open up the internet browser that is defined in Rs global environment. Unfortunetly the user never gets to see the browser, because it gets executed on the remote machine. And usually you would expect that the URL and the code is printed to console in order to open the browser on your local machine, as it is already defined here.Our workaround for this in the Jupyter notebook would be to run the authentication in a temporary non-interactive state with
rlang::with_interactive({...}, value=FALSE). This way we keep the general interactiveness of Jupyter and disable it once during authentication. So far, so good.Now, there is still a big issue with this approach. This line is blocking this non-interactive state. As I understand, the intention for
oauth_flow_check(...,interactive=TRUE)is a legacy thing, that is was assumed that the user needs to be actively involved by direct interaction with the browser. To cut it short, this line throws an error, because this "interactive state" is required and prevents the printing of the URL and the code from ever being called.My question is whether the
oauth_flow_checkis really required here or the default value forinteractivecould be changed torlang::is_interactive()?Best regards,
Florian