@truenas/api-client 3.0.3 → 3.0.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +43 -0
- package/dist/index.cjs +1013 -887
- package/dist/index.cjs.map +1 -1
- package/dist/index.d.cts +150 -49
- package/dist/index.d.ts +150 -49
- package/dist/index.js +1013 -887
- package/dist/index.js.map +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -82,6 +82,49 @@ client.api.events('app.query').subscribe(event => {
|
|
|
82
82
|
});
|
|
83
83
|
```
|
|
84
84
|
|
|
85
|
+
### Reaching an appliance over http
|
|
86
|
+
|
|
87
|
+
By default the client discovers over `https://` and connects over `wss://`,
|
|
88
|
+
which is what an appliance serves. An appliance reached without TLS needs
|
|
89
|
+
`protocol`:
|
|
90
|
+
|
|
91
|
+
```typescript
|
|
92
|
+
import type { ApplianceProtocol } from '@truenas/api-client';
|
|
93
|
+
|
|
94
|
+
const protocol: ApplianceProtocol =
|
|
95
|
+
location.protocol === 'http:' ? 'http:' : 'https:';
|
|
96
|
+
|
|
97
|
+
const client = await createTrueNasClient({
|
|
98
|
+
uuid, hostnames: [location.host], enabled: true, protocol,
|
|
99
|
+
});
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
It selects both halves of the transport — `https:` gives `https` discovery and a
|
|
103
|
+
`wss` socket, `http:` gives `http` and `ws` — and defaults to `https:`, so
|
|
104
|
+
existing callers are unaffected.
|
|
105
|
+
|
|
106
|
+
`protocol` describes the **appliance**, not the page. Reading it from
|
|
107
|
+
`location.protocol` is right when the appliance serves the page, which is the
|
|
108
|
+
same-origin case this exists for. A page served from somewhere else — a dev
|
|
109
|
+
server on `http://localhost:5173` talking to an https appliance — must pass what
|
|
110
|
+
the *appliance* uses. Getting it wrong breaks both halves but reports only one:
|
|
111
|
+
discovery's `fetch` follows the redirect and looks fine, while the socket opens
|
|
112
|
+
`ws://`, meets the same redirect, and fails the handshake without naming the
|
|
113
|
+
scheme.
|
|
114
|
+
|
|
115
|
+
Omitting it against a plaintext appliance fails the other way, and more quietly.
|
|
116
|
+
Discovery tries `https://`, `fetch` rejects, and the factory cannot tell that
|
|
117
|
+
apart from the CORS block that v25.10.0 has on `/api/versions` — so it takes the
|
|
118
|
+
fallback and hands back a client pinned to `v25.10.0` on `/api/v25.10.0`, with
|
|
119
|
+
only a `logger.warn` to say so. Against a v26 or v27 box that is a wrong-version
|
|
120
|
+
client that looks configured. If the appliance is plaintext, say so.
|
|
121
|
+
|
|
122
|
+
Narrow rather than cast: `location.protocol` is a `string`, and it is genuinely
|
|
123
|
+
`file:` for a locally-opened page or `chrome-extension:` in an extension. Both
|
|
124
|
+
halves fall back to the encrypted scheme for anything off-contract, so a bad
|
|
125
|
+
value cannot downgrade the transport — but the compiler will not stop you
|
|
126
|
+
asserting one into this option, and it will not be the value you meant.
|
|
127
|
+
|
|
85
128
|
### Naming a version
|
|
86
129
|
|
|
87
130
|
By default the version is discovered at runtime while the types are fixed at
|