LinkPort/docs/target-accounts.md

Target Accounts

Optional account remarks

Target accounts use remark as optional descriptive metadata. The remark may be empty and is limited to 100 UTF-8 bytes; account identity and credential retention continue to use the stable account id, while authentication uses username and the selected credential fields. Lists, mappings, connection tests, cluster controls, health results and expiry warnings display the remark when present and otherwise fall back to the username or a localized “no remark” label.

New API responses and persisted target data contain remark and never write an account-level name. For compatibility, requests, imports, backups and sync payloads from older versions may still provide name; an explicitly supplied remark, including an empty string, takes precedence. On startup, encrypted current targets, target history and configuration templates are migrated by primary key to the canonical field. The encrypted payload format and SQLite schema do not change, and the migration is idempotent. A downgrade requires a backup because older versions may not understand the canonical remark field.

New and edited target drafts can be tested before saving. Select an account in the editor footer; an account-free Redis or MongoDB draft has no selector and tests with an empty accountId. The test uses the current draft and retains omitted saved credentials by account ID. This avoids persisting trial connection settings. See draft connection testing for protocol coverage, temporary SSH host confirmation and persistence boundaries.

A target maintains one account list for all protocols. Accounts share the endpoint, proxy route and SSH host identity. Each account has a stable ID, optional remark, username and password, or SSH private key and passphrase. Redis and MongoDB support 0 to 32 accounts; all other account-based protocols support 1 to 32. TCP remains account-free and does not expose this list. There is no separate primary credential form.

Empty Passwords And Unauthenticated Targets

In the target editor's accounts tab, a new password-based account may leave its password empty. A username is required except for Redis password-only authentication, and the upstream server decides whether a named account may connect with an empty password. This does not bypass the server's authentication rules. SSH/SFTP private-key login remains available.

Redis follows its protocol's three authentication forms. An empty account list or an account using authMethod: "none" sends no AUTH; an empty username with a non-empty password sends AUTH password; and a non-empty ACL username sends AUTH username password (the Redis default identity is compatible with the single-argument form). A password-mode Redis account with both fields empty is invalid, and whitespace is not treated as an empty username. MongoDB and every other named-account protocol continue to require a username for password mode.

For an existing account, a blank password input retains the saved password. Select “使用空密码（清除已保存密码）” to explicitly use an empty password. Draft tests and saving both send password: "" when selected; testing alone does not erase the stored secret. Unselected empty inputs omit the field and preserve the existing value.

MongoDB, Redis, HTTP and HTTPS accounts additionally offer “无认证”. This stores authMethod: "none", hides username/password inputs and clears the account's credentials and key/certificate references when saved. The account ID remains, so gateway account mappings do not need to change. MongoDB skips upstream SCRAM; Redis skips upstream AUTH; HTTP(S) sends no upstream Basic credentials and strips the gateway Authorization header. Credential expiration and gateway login rules remain enforced. Normal target authentication failures never automatically retry anonymously. Redis Sentinel keeps its existing explicit compatibility option “自动尝试目标账号或无认证”: with no sentinelAccountId, discovery first tries the selected data account and may retry the Sentinel without authentication. Selecting a Sentinel account disables that fallback.

Redis and MongoDB can also save an empty account list when the upstream service has no authentication configured. In that state, draft tests, saved-target tests, topology discovery, health checks and gateway connections use an empty account selection. Redis sends no upstream AUTH, and MongoDB skips SCRAM. Adding any account immediately restores the normal rule: every gateway, test and discovery operation must select a valid account ID. An empty list is therefore not a fallback after rejected credentials, and removing all accounts remains blocked while a saved account is still referenced by a gateway.

Redis and MongoDB gateways may likewise leave the gateway account list empty and accept clients without local authentication. A Redis gateway account may instead have an empty username and a non-empty password; clients then use AUTH password or the equivalent HELLO ... AUTH default password. That password-only identity and an explicit default gateway username cannot coexist because both represent the same Redis protocol identity. Other account-based gateway protocols still require at least one client account and a username; TCP remains account-free. Gateway authentication remains independent of upstream authentication.

Authentication Compatibility Matrix

Service	Target authentication	Gateway client authentication
Redis	None, password only, or ACL username and password	None, password only, or ACL username and password
MongoDB	None, or SCRAM username and password	None, or local SCRAM username and password
MySQL	Username and optional password	Username and password
PostgreSQL	Username and optional password	Username and password
SQL Server	Username and optional password	Username and password
RabbitMQ	Username and optional password	Username and password
HTTP / HTTPS	Explicit no-auth account, or Basic username and optional password	Basic username and password
SSH / SFTP	Username with password or private key	Username with password or authorized key
TCP	No protocol account	No protocol account

"Optional password" means linkport can send an empty password for a named account; the target server still decides whether it is valid. It does not mean linkport retries a rejected login anonymously. Non-SSH/SFTP services reject private-key and unknown authentication methods instead of silently ignoring them.

An unauthenticated target must actually permit the requested operation. A successful handshake or metadata test does not grant access to all databases or commands. Other named-account protocols do not offer anonymous mode; use a valid username and an empty password only when permitted by their server configuration. TCP mapping remains account-free and is not changed by this feature.

Importing a URL containing credentials switches the selected account back to password mode and cancels the explicit empty-password choice. URLs without credentials retain the existing authentication mode. Existing configurations are unchanged; this uses the existing encrypted account JSON, with no schema migration. Before downgrading to a version without anonymous-account support, reconfigure accounts using authMethod: "none". See testing and change rationale for validation scope.

Gateway Account Mapping

Each gateway account may select its own same-protocol target service and account. The gateway editor's accounts tab shows one account at a time. Use the searchable account selector to switch accounts; “添加账号” immediately selects the new account and focuses its username. Login, target, permissions, public keys (SSH/SFTP) and additional settings have separate tabs, so adding accounts does not extend the page. Switching accounts retains all drafts until “保存配置”. Validation selects the account and settings tab containing the invalid field.

This replaces stacked account forms because adding or finding an account required repeated scrolling. The selector and grouped fields keep editor height independent of account count. See the change rationale for design choices, data compatibility and validation boundaries.

New and edited mappings are selected from each gateway account. An explicit account targetId requires an account belonging to that target; it never reuses an account from another target, even when account IDs match. Legacy gateway-level targetId and targetAccountId values remain readable for API and stored-data compatibility, but the gateway editor no longer exposes a shared service selector for any protocol. When a legacy gateway with real gateway accounts is edited and saved, the draft expands the legacy target into every account's targetId and targetAccountId, then clears the top-level mapping. Account-free Redis, MongoDB and TCP gateways retain the top-level fields because an empty gateway-account ID is their persisted account endpoint. Each account route uses its own endpoint, outbound transport, TLS settings and credentials. Backups and WebDAV sync include these mappings; referenced targets and credentials remain protected. An empty target-account ID is valid only for TCP or while a Redis/MongoDB target still has no accounts.

Drag an individual gateway account in “拖拽连线” to change only its route. Each account has a separate line, including accounts sharing a destination. Clicking the source and destination is also supported. Running gateways accept mapping changes for new connections without restarting the listener. Redis clients must reconnect to authenticate as an account routed to a different target.

Many gateway accounts can map to the same target account, even when the target has multiple accounts. Select the destination in each gateway account's target tab. Each account displays its effective target account. Gateway passwords, source restrictions and access policies remain separate; sharing an upstream account does not merge gateway identities or grant access to other target accounts.

In the target editor, use the accounts tab to maintain accounts. In the gateway editor, select the target and then its target account for each gateway account. The current account schema keeps compatibility with the legacy credential fields while normalizing account metadata to remark. Old account-based targets do not need to be recreated solely because they used name; the startup migration and JSON compatibility reader preserve their stable account IDs and credentials. Old gateways still require an explicit account selection before they can start, except when they bind an account-free Redis or MongoDB target. There is no reserved default account or credential migration. Changing targets resets the account selection: a single account is selected automatically, while multiple accounts require an explicit choice. In “拖拽连线”, drag or click a gateway-account row and then a target-account row. Both service cards are informational and do not implicitly select an account. Redis and MongoDB configurations with empty account arrays display a UI-only “无认证账号” row on the corresponding side; TCP displays “空账号”. Saving any of these routes keeps the account ID empty and does not create a credential record. Gateway cards continue to summarize current routes.

The gateway authenticates clients with gateway credentials and connects upstream with the selected account. A root account is a direct root login, not sudo or automatic elevation. The target SSH server must allow that login. Authentication failure does not fall back to another account.

Gateway credentials, client public keys and per-account policies are maintained in the gateway editor's separate accounts tab. Source IP/CIDR lists use one input with comma-separated entries. Any entry may match within a list, but a client must satisfy both the gateway list and its account list. An empty account list adds no restriction; an empty gateway list does not restrict sources globally.

File credentials are maintained in Asset Management. SSH/SFTP target accounts select a private-key asset and, optionally, a matching SSH user-certificate asset. An encrypted private key still takes its passphrase from the target account. Gateway accounts select an SSH public-key-list asset. Target TLS selects a TLS/CA certificate asset. Existing inline material remains compatible; selecting an asset replaces it with a shared reference. See file assets for upload, replacement, deletion protection and backup behavior.

In the connection view, administrators can disconnect a stopped gateway after confirmation. This clears the target link and all target-account mappings while retaining gateway accounts and credentials. The gateway must be linked again before it can start. Running gateways must be stopped before disconnecting.

Accounts are encrypted with the existing target configuration in SQLite. Public target and gateway responses redact passwords, private keys and passphrases. Omitted credentials retain their values by account ID; explicit empty values in the API clear them. The editor retains blank credential inputs and has an explicit passphrase-clear checkbox. Changing an account ID creates a distinct identity.

Referenced accounts cannot be removed until all gateways using them are rebound or deleted. Changing a gateway account requires stopping that gateway. Target connection/account changes require stopping all referencing gateways, consistent with the existing target configuration policy.

Do not expose the development management UI to gateway clients. Production management requires authentication; administrators can access existing credential reveal functions. Gateway authentication does not grant management API access.

Validation covers account selection, redaction, credential retention, deletion protection and local SSH fixture authentication. It does not establish that a particular production host permits root login.

Account-free Redis and MongoDB

Redis and MongoDB targets may use an empty accounts array to represent an upstream that accepts anonymous connections. Redis and MongoDB gateways may also use an empty gatewayAccounts array to accept clients without gateway credentials. Once an account is configured, the existing account-selection and credential requirements apply again. The connection canvas represents each empty Redis/MongoDB list as one “无认证账号” endpoint; TCP uses an equivalent “空账号” endpoint. Their persisted IDs remain empty.