fix(AdminSettings): test Websocket connection

[Antreesy]

☑️ Resolves

Allows to test websocket connection with HPB in Admin settings (before users will face it in Talk interface): client attempts to establish new websocket, then:

• clean close on success
• throw error if any

🖌️ UI Checklist

🖼️ Screenshots / Screencasts

Small screen	Wide screen

🚧 Tasks

• Handle NC <-> HPB servers time sync issue
• Handle other cases that could be checked?

🏁 Checklist

• 🌏 Tested with different browsers / clients:
  • Chromium (Chrome / Edge / Opera / Brave)
  • Firefox
  • Safari
  • Talk Desktop
  • Not risky to browser differences / client

[Antreesy]

I'm lacking knowledge on how else this connection could fail (and how to reproduce it), so wouldn't mind a second opinion here
cc @danxuliu @fancycode @SystemKeeper

[fancycode]

Another thing you could test here is sending a hello request after the connection was established. This will verify that the backend url and shared secret are correctly configured in the signaling server.

[fancycode]

Regarding testing: this will also fail if the signaling server url is incorrect and the request can't be upgraded to a WebSocket. This can be seen in the response (could be 404 for unknown urls or something like 400 for valid urls that don't support WebSocket), but I'm not sure if you get all the details from the JavaScript API.

[fancycode]

Another thing you could test here is sending a hello request after the connection was established. This will verify that the backend url and shared secret are correctly configured in the signaling server.

As I had a HPB setup support request from a customer yesterday where the backend url was a problem, this would be really great to test from the admin settings. Maybe you could also show the backend url ithat Talk will send to the signaling server in the UI so the user can compare with the configuration of the signaling server (see https://github.com/strukturag/nextcloud-spreed-signaling/blob/0a04ea290969cfe1ebc3ef3aaeeae1bdc49ea552/server.conf.in#L125-L126).

• URL used for backend requests:

  spreed/lib/Signaling/BackendNotifier.php

  Line 122 in bab0241

  $headers['Spreed-Signaling-Backend'] = $this->urlGenerator->getAbsoluteURL('');

• URL used for hello requests:

  spreed/lib/Config.php

  Line 611 in bab0241

  'iss' => $this->urlGenerator->getAbsoluteURL(''),

[Antreesy]

Will take a look

UPD: Assume that urlGenerator->getAbsoluteURL('') returns the same as getBaseUrl() (from local tests at least):

https://github.com/nextcloud/server/blob/9836e9b16484582d309c8437ab46d82e34956941/lib/private/URLGenerator.php#L314-L323

https://github.com/nextcloud-libraries/nextcloud-router/blob/f24954923c99210bf6f78d8cb420563b95e5449b/lib/index.ts#L204-L211

[danxuliu]

In my development environment if the secret is wrong the WebSocket is still successfully connected and no error message is shown.

I guess it is caused by using the hello protocol version 2.0 if available; if I am not mistaken in that case the signaling server does not send a request to the Nextcloud server to verify the authentication parameters, so the Websocket connection can be established even if the secret is wrong (although then an error will be received as soon as the signaling server sends a request to the Nextcloud server, for example, when the user tries to join a conversation).

If my guess is right then it would be better to use the hello protocol version 1.0 for the test, independently of what is supported by the signaling server. @fancycode Would there be any drawbacks with that? And even more important, is my guess right, or am I missing something? :-)

[nickvergessen]

Works better then before and is blocking an upcoming feature, so fine by me to merge like this and look into secret verification as a follow-up?

[fancycode]

In my development environment if the secret is wrong the WebSocket is still successfully connected and no error message is shown.

I guess it is caused by using the hello protocol version 2.0 if available; if I am not mistaken in that case the signaling server does not send a request to the Nextcloud server to verify the authentication parameters, so the Websocket connection can be established even if the secret is wrong (although then an error will be received as soon as the signaling server sends a request to the Nextcloud server, for example, when the user tries to join a conversation).

Right, the hello v2 was introduced to get rid of the request to verify the tickets in the hello request. With v2, the public key is fetched from the capabilities (and cached), so the provided ticket can be checked without additional requests.

If my guess is right then it would be better to use the hello protocol version 1.0 for the test, independently of what is supported by the signaling server. @fancycode Would there be any drawbacks with that? And even more important, is my guess right, or am I missing something? :-)

That would be a way to check the secret, however you will not test that v2 also works ;) So the best would be to check a v1 hello to verify the secret and v2 to verify the public key from the capabilities. Note that you will have to establish a new WebSocket connection for each test (sending a second hello through an already established session will not work).

[Antreesy]

Thanks, @danxuliu @fancycode !

Attempt is made at #14121.
Although I'm unable to catch failed secret:

Maybe, there is no actual request made (as in BackendNotifier.php)