RFC: Sunshine API and Web UI

[TheElixZammuto]

Hi, at the moment Sunshine exposes both an HTTPS API (With basic authentication) and a Web UI made by a few static files wrapped toghther.

The problem is that HTTPS on Local Addresses is a very complex topic that would require many workaround for not showing the self-signed error message. Also I noticed people want to have an API for integration for Sunshine (which is already available - but with the limitations I talked earlier and it's undocumented at the moment).

I would like to make these changes, but I would love to have your feedback on the matter:

1. Replace HTTPS with HTTP on a localhost only listen - this way we can make the app more secure and less troublesome for setup, for external service exposition there are solutions like Nginx that can allow that
2. Remove Basic Authentication - Auth should be handled by a better suited tool on environments that would require to make the UI available by other users on the LAN (tools like Nginx or oauth2-proxy are perfect for this job)
3. Document the actual API - The Web UI only uses REST API for communicating with Sunshine, by making a documentation available we can help people who want to integrate Sunshine with their solution
4. Add other APIs - You tell me which one :^)
5. Electron - I would like to make an Electron app to make some feature that are not possible with the Web API Alone (like a server file picker) and also make some integrations on that side that can make the Core Software as lean as possible (like importer from other game services)

What do you think about these changes?

[jorys-paulin]

1. Unencrypted HTTP on localhost seems like a bad idea, a malware could sniff the traffic, get access to the API and in the end remote access to the computer
2. I don't know what other simple auth methods could be implemented, maybe per-client secrets/token, but that's basically one username and password for each device
3. Totally okay for this, a nice documentation is always nice for non C++ devs like me
4. Create, edit and delete specific applications instead of updating everything at once
5. Electron adds a lot of complexity, for small UIs like dialogs I would prefer a native solution. Importers could be separate projects that interact with Sunshine via the API instead.

[TheElixZammuto]

1. Keep in mind that applications that listen on localhost only do not send traffic over the network, so the only way to sniff traffic is to actually have physical access to the machine - which at that point is ka-bum. Since it's listening to localhost opening port for the Web UI would not work, but it would be necessary to have something like a reverse proxy

2. The idea is to completely remove the authentication. If the users want to expose the Web UI to other devices they should authenticate on the Reverse proxy side - and the possibilities are endless in that case (IP FIlter, basic authentication, oauth2, LDAP and so on)

3. Yeah maybe not electron, but wrapping some sort of WebView over these native API can be very useful and definetly more lightweight (like https://neutralino.js.org/ which leverages the Browser's default web browser)

[TheChoconut]

No authentication?
I've been thinking about this and I do not like the idea of removing HTTPS entirely. I think that HTTPS should be kept with a self-signed certificate but allow a user to enable HTTP API.

If you remove authentication completely, you have multiple problems:

1. if you allow access to everyone, CSRF is a problem. Anyone can make a website that will make a request to sunshine endpoint that will spam a command (or even worse, change sunshine settings!). For every GET request I can just make some site load an image with URL to that sunshine endpoint and it's going to trigger an action.
2. if you block access from browsers, it can still be faked by an app. Since sunshine is running as admin, I think it could be problematic to leave unprotected access to the API.

Self signed certificates aren't that bad and I think for basic users we could install the certificate in the root store for localhost. For more advanced usage, we could allow custom certificates for reverse proxying.

Remove web UI
I think the web UI should be moved away from sunshine and keep only HTTP(s) API.
All sunshine UI clients would be moved to other projects that would interact with the sunshine API... For options like UI dialogs for pairings, there's also a possibility of adding IPC API (but that's just an idea)...

[ReenigneArcher]

Regarding item 1. Is it possible to have this configurable? Alternatively is it possible to run both http and https simultaneously (obviously on two different ports)? I personally don't think https is required on local network and there are many noteable self hosted web servers that run on http locally.

Regarding item 3. Is it possible to have the api return a list of options including:

• Name
• Description
• Possible values
  • friendly name of each value
  • description of each option

I did something similar in python, but getting some info was quite challenging. Especially regarding details of the monitors, graphics card, sound cards, etc. I hard coded each option in though, would be much nicer to pull from an api.

Regarding item 5. That sounds cool. If importing games would be automatic, it should be off by default.

[PapyKahan]

I assume that you're talking about configuration API, not GFE one.

1. Totally agree with you.
2. Agree to. We could also offer the possibility to configure mutual TLS Auth for Rest APIs for those who want to expose the service and have knowledge to do so.
3. The whole project needs documentation to help newcomers and maintenance.
4. No idea yet.
5. I'm not a UI guy at all. CLIs are my friends and help automation.

Do you also plan to continue to use Simple-Web-Server component ? The submodule is still pointing to Loki's repo.

[AeliusSaionji]

1. https with self signed cert seems to be a pretty normal and widely used approach, and I see no reason to change this in sunshine. Give the user the option for http, but do not remove https, and not make http the default.
2. I agree basic auth should go, but rather than going all in on setting up a more bigger and capaple httpd-

why not pivot to (well documented) text file configs and a simple local utility for pin pairing? This would eliminate the whole need for an httpd entirely, and could be used for other aspects, thus neatly resolving 1 and 5 as well.

Before we start talking game-library importing though, there's the rather serious problem that sunshinesvc configuration currently launches games as the TrustedInstaller user. For users of the service, it is entirely inadvisable to launch anything other than Desktop, at the moment...

[PapyKahan]

"why not pivot to (well documented) text file configs and a simple local utility for pin pairing? This would eliminate the whole need for an httpd entirely, and could be used for other aspects, thus neatly resolving 1 and 5 as well."

Just had the same reflection. A REST API seems overkill for a simple configuration file.

Sunshine will still need an httpd for GFE API, but GFE endpoint must not be used for pin validation.

[User-green]

API suggestion:
https://github.com/orgs/LizardByte/discussions/586