mirror of
https://github.com/m1k1o/neko.git
synced 2026-11-03 00:11:48 -06:00
Remove legacy mode.
- Deleted the legacy WebSocket client implementation (`wstoclient.go`) and its test file (`wstoclient_test.go`). - Removed legacy handling from the HTTP manager, including legacy proxy setup and routing. - Cleaned up session management by removing legacy host checks and related functions. - Eliminated the legacy WebRTC handler and its associated logic. - Updated session interface to remove legacy methods. - Removed legacy API documentation and configuration options from migration guide and help files.
This commit is contained in:
Miroslav Šedivý
@@ -1,14 +1,6 @@
|
||||
# Migration from V2
|
||||
|
||||
Currently, Neko is in compatibility mode, meaning that as soon as a single V2 configuration option is set, the legacy mode is enabled. This approach allows for a smooth transition from V2 to V3, where it does not expose the V2 API for new users but still allows existing users who use the old configuration to continue using it as before.
|
||||
|
||||
The legacy mode includes a compatibility layer that allows V2 clients to connect to V3. Currently, the **client is not compatible with V3**, so the legacy mode is enabled by default. It can be explicitly enabled or disabled by setting the `NEKO_LEGACY` environment variable to `true` or `false`.
|
||||
|
||||
:::warning
|
||||
The legacy mode is **still used by the client**. It is recommended to migrate to the new configuration options, but do not disable the legacy mode unless you are using a new client that is compatible with V3 (e.g., [demodesk/neko-client](https://github.com/demodesk/neko-client)). Once the new client is released, the legacy mode will be automatically removed from the server.
|
||||
:::
|
||||
|
||||
If you set both V3 and V2 configuration options, the V2 configuration options will take precedence over the V3 configuration options. This is to ensure that the legacy mode works as expected and does not break existing configurations.
|
||||
Neko v3 accepts many V2 configuration options as deprecated aliases, which are mapped to their V3 equivalents. When both forms are set, the V2 option takes precedence. The V2 API and client compatibility layer have been removed; clients must use the V3 API.
|
||||
|
||||
## Docker Images {#docker}
|
||||
|
||||
@@ -20,7 +12,7 @@ All applications available in the V2 images are also available in the V3 images.
|
||||
|
||||
## Configuration {#config}
|
||||
|
||||
V3 is compatible with V2 configuration options when legacy support is enabled. You should be able to run V3 with the V2 configuration without any issues.
|
||||
V3 continues to accept the V2 configuration aliases listed below. This does not enable or restore the V2 API.
|
||||
|
||||
The configuration in Neko V3 has been structured differently compared to V2. The V3 configuration is more modular and allows for more flexibility. The V3 configuration is split into multiple sections, each section is responsible for a specific part of the application. This allows for better organization and easier management of the configuration.
|
||||
|
||||
@@ -63,9 +55,7 @@ See the V3 configuration options for the [WebRTC Video](/docs/v3/configuration/c
|
||||
| `NEKO_MAX_FPS` | **removed**, use [custom pipeline](/docs/v3/configuration/capture#video.gst_pipeline) instead |
|
||||
|
||||
|
||||
:::warning Limitation
|
||||
V2 did not have client-side cursor support, the cursor was always part of the video stream. In V3, the cursor is sent separately from the video stream. Therefore, when using legacy configuration, there will be two video streams created, one with the cursor (for V2 clients) and one without the cursor (for V3 clients). Please consider using new configuration options if this is not the desired behavior.
|
||||
:::
|
||||
V2 video settings map to a single V3 video pipeline. The V3 client renders the cursor separately from the video stream.
|
||||
|
||||
### WebRTC Audio {#config.audio}
|
||||
|
||||
@@ -109,7 +99,7 @@ See the V3 configuration options for the [Authentication](/docs/v3/configuration
|
||||
| `NEKO_PASSWORD` | `NEKO_MEMBER_MULTIUSER_USER_PASSWORD` with `NEKO_MEMBER_PROVIDER=multiuser` |
|
||||
| `NEKO_PASSWORD_ADMIN` | `NEKO_MEMBER_MULTIUSER_ADMIN_PASSWORD` with `NEKO_MEMBER_PROVIDER=multiuser` |
|
||||
|
||||
In order for the legacy authentication to work, you need to set [Multi-user](/docs/v3/configuration/authentication#member.multiuser).
|
||||
The V2 password settings map to the [Multi-user](/docs/v3/configuration/authentication#member.multiuser) provider.
|
||||
|
||||
:::warning Limitation
|
||||
V2 clients might not be compatible with any other authentication provider than the `multiuser`.
|
||||
@@ -131,7 +121,7 @@ See the V3 configuration options for the [WebRTC](/docs/v3/configuration/webrtc)
|
||||
|
||||
### Full V2 Configuration Reference {#config.full}
|
||||
|
||||
Here is a full list of all the configuration options available in Neko V2 that are still available in Neko V3 with legacy support enabled.
|
||||
Here is a full list of V2 configuration options that remain available as deprecated aliases in Neko V3.
|
||||
|
||||
import { ConfigurationTab } from '@site/src/components/Configuration';
|
||||
import configOptions from './help.json';
|
||||
@@ -142,95 +132,10 @@ See the full [V3 configuration reference](/docs/v3/configuration/#full) for more
|
||||
|
||||
## API {#api}
|
||||
|
||||
V3 is compatible with the V2 API when legacy support is enabled. There was specifically created a compatibility layer (legacy API) that allows V2 clients to connect to V3. The legacy API is enabled by default, but it can be disabled if needed. In later versions, the legacy API will be removed.
|
||||
|
||||
### Authentication {#api.auth}
|
||||
|
||||
In V2 there was only one authentication provider available, as in V3 called the [`multiuser`](/docs/v3/configuration/authentication#member.multiuser) provider. The API knew based on the provided password (as `?pwd=` query string) if the user is an admin or not.
|
||||
|
||||
Since V3 handles authentication differently (see [API documentation](/docs/v3/api#authentication)), there has been added `?usr=` query string to the API to specify the username. The password is still provided as `?pwd=` query string. The `?usr=` query string is still optional, if not provided, the API will generate a random username.
|
||||
|
||||
:::warning Limitation
|
||||
For every request in the legacy API, a new user session is created based on the `?usr=&pwd=` query string. The session is destroyed after the API request is completed. So for HTTP API requests, the sessions are short-lived but for WebSocket API requests, the session is kept alive until the WebSocket connection is closed.
|
||||
:::
|
||||
|
||||
Only the [`multiuser`](/docs/v3/configuration/authentication#member.multiuser) provider (or the [`noauth`](/docs/v3/configuration/authentication#member.noauth) provider) is supported without specifying the `?usr=` query string.
|
||||
|
||||
### WebSocket Messages {#api.ws}
|
||||
|
||||
Since WebSocket messages are not user-facing API, there exists no migration guide for them. When the legacy API is enabled, the user connects to the `/ws` endpoint and is handled by the compatibility layer V2 API. The V3 API is available at the `/api/ws` endpoint.
|
||||
|
||||
V2 used to send WebSocket ping messages every 60 seconds, whereas V3 sends them every 10 seconds and additionally uses a heartbeat mechanism to verify if the connection is still active.
|
||||
|
||||
### WebRTC API {#api.webrtc}
|
||||
|
||||
Since the WebRTC API is not user-facing API, there exists no migration guide for it. It has been changed to Big Endian format (previously Little Endian) to allow easier manipulation on the client side.
|
||||
V2 created a new data channel on the client side, V3 creates a new data channel on the server side. That means, the server just listens for a new data channel from the client and accepts it with the legacy API handler. It overwrites the existing V3 data channel with the legacy one.
|
||||
|
||||
### HTTP API {#api.http}
|
||||
|
||||
The V2 version had a very limited HTTP API, the V3 API is much more powerful and flexible. See the [API documentation](/docs/v3/api) for more details.
|
||||
|
||||
#### GET `/health` {#api.http.health}
|
||||
|
||||
Migrated to the [Health](/docs/v3/api/healthcheck) endpoint for server health checks.
|
||||
|
||||
Returns `200 OK` if the server is running.
|
||||
|
||||
#### GET `/stats` {#api.http.stats}
|
||||
|
||||
Migrated to the [Stats](/docs/v3/api/stats) endpoint for server statistics and the [List Sessions](/docs/v3/api/sessions-get) endpoint for the session list.
|
||||
|
||||
Returns a JSON object with the following structure:
|
||||
|
||||
```json
|
||||
{
|
||||
// How many connections are currently active
|
||||
"connections": 0,
|
||||
// Who is currently having a session (empty if no one)
|
||||
"host": "<session_id>",
|
||||
// List of currently connected users
|
||||
"members": [
|
||||
{
|
||||
"session_id": "<session_id>",
|
||||
"displayname": "Name",
|
||||
"admin": true,
|
||||
"muted": false,
|
||||
}
|
||||
],
|
||||
// List of banned IPs and who banned them as a session_id
|
||||
"banned": {
|
||||
"<ip>": "<session_id>"
|
||||
},
|
||||
// List of locked resources and who locked them as a session_id
|
||||
"locked": {
|
||||
"<resource>": "<session_id>"
|
||||
},
|
||||
// Server uptime
|
||||
"server_started_at": "2021-01-01T00:00:00Z",
|
||||
// When was the last admin or user left the session
|
||||
"last_admin_left_at": "2021-01-01T00:00:00Z",
|
||||
"last_user_left_at": "2021-01-01T00:00:00Z",
|
||||
// Whether the control protection or implicit control is enabled
|
||||
"control_protection": false,
|
||||
"implicit_control": false,
|
||||
}
|
||||
```
|
||||
|
||||
#### GET `/screenshot.jpg` {#api.http.screenshot}
|
||||
|
||||
Migrated to the [Screenshot](/docs/v3/api/screen-shot-image) endpoint for taking screenshots.
|
||||
|
||||
Returns a screenshot of the desktop as a JPEG image.
|
||||
|
||||
#### GET `/file` {#api.http.file}
|
||||
|
||||
The whole functionality of file transfer has been moved to a [File Transfer Plugin](/docs/v3/configuration/plugins#filetransfer).
|
||||
The V2 API compatibility layer has been removed. Migrate clients to the [V3 API](/docs/v3/api); the V2 `/ws` endpoint and V2 HTTP endpoints are no longer available.
|
||||
|
||||
## Limitations {#limitations}
|
||||
|
||||
In v2, locks and muted users were managed using a simple map that tracked who set the lock and what was locked. In v3, locks are now implemented as setting options and no longer store the `session_id` of the user who applied the lock. As a result, if a client refreshes the page or reconnects, the lock information is lost, and the user who set the lock is displayed as `Somebody`.
|
||||
|
||||
Additionally, when using the legacy API with a v2 client, API calls occur in a different order than expected. The client first retrieves the session list before registering the user, meaning the current `session_id` is not known when the session list is fetched. That means, the current user appears as `Somebody` in the session list.
|
||||
|
||||
Currently, the v3 has no native support for pipeline generation, meaning that the user has to manually specify the pipeline for video and audio if he wants to customize it. The v2 had a simple built-in support for setting the video bitrate, fps, audio bitrate, and hardware encoding. Since the introduction of multiple video pipelines in v3, this feature has been removed.
|
||||
|
||||
@@ -1,12 +1,4 @@
|
||||
[
|
||||
{
|
||||
"key": [
|
||||
"legacy"
|
||||
],
|
||||
"type": "boolean",
|
||||
"defaultValue": "true",
|
||||
"description": "enable legacy mode"
|
||||
},
|
||||
{
|
||||
"key": [
|
||||
"logs"
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
|
||||
--legacy enable legacy mode (default true)
|
||||
|
||||
--logs save logs to file
|
||||
|
||||
--cert string path to the SSL cert used to secure the neko server
|
||||
|
||||
Reference in New Issue
Block a user