/api/pin always returns true when there is a pairing request

[causa-prima]

Is there an existing issue for this?

• [x] I have searched the existing issues

Is your issue described in the documentation?

• [x] I have read the documentation

Is your issue present in the latest beta/pre-release?

I'm too lazy to test

Describe the Bug

Environment:

• Client: Moonlight Portable v6.1.0

Steps to reproduce:

1. Add the server to Moonlight and try to pair it -> Moonlight should show the Pairing Dialog with a PIN to enter in Sunshine
2. Do a curl request to the API with any but the PIN shown, i.e. e.g. curl -u username:password -X POST -k -v https://localhost:47990/api/pin -d "{\"name\":\"Laptop\",\"pin\":\"9875\"}"
3. The response status is true.

The response I got for the show request:

(deck@steamdeck ~)$ curl -u username:password -X POST -k -v https://localhost:47990/api/pin -d "{\"name\":\"Laptop\",\"pin\":\"9875\"}"
Note: Unnecessary use of -X or --request, POST is already inferred.
* Host localhost:47990 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:47990...
* connect to ::1 port 47990 from ::1 port 36678 failed: Connection refused
*   Trying 127.0.0.1:47990...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / RSASSA-PSS
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=Sunshine Gamestream Host
*  start date: Mar 31 10:28:58 2025 GMT
*  expire date: Mar 26 10:28:58 2045 GMT
*  issuer: CN=Sunshine Gamestream Host
*  SSL certificate verify result: self-signed certificate (18), continuing anyway.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to localhost (127.0.0.1) port 47990
* using HTTP/1.x
* Server auth using Basic with user 'causa-prima'
> POST /api/pin HTTP/1.1
> Host: localhost:47990
> Authorization: Basic Y2F1c2EtcHJpbWE6Z29kMmJsaWVm
> User-Agent: curl/8.11.1
> Accept: */*
> Content-Length: 30
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 30 bytes
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 200 OK
< Content-Length: 25
<
{
    "status": "true"
}
* Connection #0 to host localhost left intact

Note: If you omit step 1, i.e. you do not open a pairing request, then any request to /api/pair returns false as expected.

Expected Behavior

The response status should be false.

Additional Context

I'm a contributor to decky-sunshine, a Decky Loader plugin that enables Steam Deck users to easily use Sunshine in game mode. The plugin uses the REST api to communicate with Sunshine. I'm currently working on the pairing process and noticed that /api/pin seems to always return true if there is an open pairing request, even when sending the wrong pin.

Host Operating System

Linux

Operating System Version

Steam OS 3.7.8

Architecture

amd64/x86_64

Sunshine commit or version

2025.122.141614

Package

Linux - flathub/flatpak

GPU Type

AMD

GPU Model

shouldn't be relevant

GPU Driver/Mesa Version

shouldn't be relevant

Capture Method

None

Config

The config is empty.

Apps

Relevant log output

There is nothing relevant in the logs

[ReenigneArcher]

Please test the latest pre-release/beta. I don't accept bug reports that don't apply to the latest commit.

If the initial checks pass then it returns the result from this function: https://github.com/LizardByte/Sunshine/blob/0de8cc864c2790196142b330735c74e434a754dd/src/nvhttp.cpp#L627-L673

If there is an exception or incorrectly formatted pin then you will get a bad request response: https://github.com/LizardByte/Sunshine/blob/0de8cc864c2790196142b330735c74e434a754dd/src/confighttp.cpp#L1010-L1037

[causa-prima]

I checked again using v2025.531.135549, same behavior.

[neverlose-lv]

I can confirm the same for me. When I send curl to /api/pin endpint - I cannot pair a device, but the response is { "status": true }. But after the response, the pairing request form the Moonlight app is still active. Moonlight does not pair.

I send curl locally. When I send curl from remonte machine - I get 403. It seems that the remote requests are not accepted. So question nr 2: how to allow to accept remote requests?

[neverlose-lv]

Update: to allow remote api call, need to set: origin_web_ui_allowed = wan in the sunshine.conf and restart sunshine/pc. Remote call have paired the Moonlight client without any problems.