Expose Companion Origin URL to modules

[thedist]

One thing I would like to do more on modules that require OAuth is to more cleanly handle the Auth Code flow by allowing users to redirect back to a modules HTTP handler, but to do this the module would need to know the origin (ie, protocol as HTTPS may or may not be enabled, domain, and port, such as http://localhost:8888/).

This would allow for modules to set their config or help file to display the exact Redirect URI that the user would need to copy/paste into their OAuth credentials settings. An example would Google Sheets is I could have the config display ${instance.origin}/instance/${instance.label}/redirect and it could show http://localhost:8888/instance/Sheets/redirect and remove the need for the user to copy/paste the code from the auth process and let it all be handled automatically.

This wont be a solution for all OAuth implementations, but for some it could make the setup less technical and smoother. Long term I'd like to see a more professional solution implemented but that's beyond the scope of this feature request.

[Julusian]

I am open to this, but I think this will be difficult to do reliably, as it will need to know the origin of the current user accessing the interface, not something static about the system.

When the user selects 0.0.0.0 as the interface to bind to and has multiple network interfaces, what ip address should be used?
I run companion behind a nginx proxy, with accessing the machine directly sometimes blocked by a firewall, so companion would need to use the dns name I am connected with.

[Julusian]

@thedist I'm curious about your thoughts on bitfocus/companion#2546
You have more experience with OAuth then I do, so a second opinion would be appreciated. This has been on my list of things that would be nice to do for a while, but I haven't been confident enough that the proposal will cover all oauth cases

[thedist]

I just added a few of my thoughts to that feature request, as well as an idea on how to handle displaying Origin but that would make this more of a Web UI feature request rather than a module-base one now.