LiveKitAPI entrypoint, ability to use a token instead of api key/secret#695
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: 2d635fc 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>
| 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.
There was a problem hiding this comment.
see reply the Rust SDK PR.
I would like the server to the be the authority on token validity, instead of the client. making validity decisions on the client relies on having a correct client clock. I don't think that's a good idea.
| * falls back to its environment variable (`LIVEKIT_URL`, `LIVEKIT_API_KEY`, | ||
| * `LIVEKIT_API_SECRET`, `LIVEKIT_TOKEN`). | ||
| */ | ||
| export type LiveKitAPIOptions = LiveKitAPICommonOptions & (ApiKeyAuth | TokenAuth); |
3 participants
Uh oh!
There was an error while loading. Please reload this page.