The whole point is you are supposed to verify the code with the one in the app to make sure no one is spying. We can’t hide it, in fact we need to show the code to verify from the modeling app

Cc @iterion @franknoirot

For whoever picks this up, the oauth2 device verification code will be provided to the client we just have to show it back to them, we do this in the cli for reference

I agree. It's like a Norman door. The page should have a single call to action that is the next step.

If the user needs to verify that it matches, the button label should be "It matches" or something indicating that the user should have actually verified something before clicking.

yeah the problem was in modeling-app we don't show them the code to verify haha but we need to!

Yeah showing the code to the user doesn't seem straightforward to me. Right now window.electron.login() awaits for the entirety of the auth flow, so there's no opportunity to show the device token in the middle. I think we need to separate it out so that there is a call before it that actually initiates the login sequence and passes back the device token to the frontend—maybe this could continue to be called getDeviceToken()—and then another function actually opens the browser and runs the auth flow, maybe called login()

Okay performing part of this splitting operation was easy. The remaining issue is that I cannot pass the handle—which contains the user_code I need to display—across the boundary of ipcMain because it is a class, not a JSON-serializable thing. And I need the .poll() method on this class to do the final login step.