LiveKitAPI entrypoint, ability to use a token instead of api key/secret#695
LiveKitAPI entrypoint, ability to use a token instead of api key/secret#695davidzhao wants to merge 5 commits into
Conversation
- added a LiveKitAPI class to reduce overhead of accessing services - ability to use token based auth instead of requiring API key/secret - comprehensive api testing - added SIPCallError
🦋 Changeset detectedLatest commit: 9d4c580 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
The generated src/version.ts tripped the REUSE license check (no SPDX header) and Prettier, and committing it isn't the repo convention — livekit-rtc gitignores its generated version.ts. Gitignore and prettier-ignore it, untrack it, and have the Test API workflow run `prebuild` to generate it before the tests (the main CI test job already builds first, which generates it). Also fix import ordering in TwirpRPC.test.ts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
LiveKitAPI fell back to process.env.LIVEKIT_TOKEN unconditionally, so a token in the environment silently shadowed an explicitly passed apiKey/secret (authHeader sends a token verbatim, skipping signing). Only fall back to LIVEKIT_TOKEN when no explicit credentials were given, and add a regression test. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
| /** API secret. Falls back to the `LIVEKIT_API_SECRET` env var. */ | ||
| secret?: string; | ||
| /** Pre-signed token, sent verbatim. Falls back to the `LIVEKIT_TOKEN` env var. */ | ||
| token?: string; |
There was a problem hiding this comment.
is there a scenario in which we'd want to allow all three to be set together?
If not, it would be nice if the types reflect a "either keys or token" approach
|
|
||
| readonly #agentDispatch: AgentDispatchClient; | ||
|
|
||
| readonly #connector: ConnectorClient; |
There was a problem hiding this comment.
nit: the livekit-server-sdk doesn't use # as private fields. They also have a couple of downsides. Would prefer these to be regular private fields
| * | ||
| * @example | ||
| * ```ts | ||
| * const api = new LiveKitAPI('https://my.livekit.cloud', { apiKey, secret }); |
There was a problem hiding this comment.
nit: if all of host, key and secret can be set via env vars, I wonder why the API here pulls out the host to be its own parameter? (those three always come together in a bundle in our docs/sdks)
| async authHeader(grant: VideoGrant, sip?: SIPGrant): Promise<Record<string, string>> { | ||
| // A pre-signed token is sent verbatim; the caller is responsible for its grants. | ||
| if (this.token) { | ||
| return { Authorization: `Bearer ${this.token}` }; | ||
| } |
There was a problem hiding this comment.
suggestion: It might be nice to expose here some sort of event the caller can use to determine if the token is expired or not. And if it is expired, then give the caller the ability to potentially regenerate it before actually making the API request.
This sets the stage well for a future TokenSource type integration (once that is officially added to node) nicely.
3 participants
Uh oh!
There was an error while loading. Please reload this page.