protocol
protocol copied to clipboard
livekit
offer new type of auth provider
livekit only support file base auth provider so I want to develop new kind of auth provider. If it is okay for the function to be officially supported, we will work on the function directly through a pull request.
The new authentication provider I'm trying to create is to be able to dynamically add api key & secret dynamically while server is running. I am thinking of using redis or mysql for storage to store the data.
We'll be working on this soon, so I'm curious if there's a chance it'll be officially included.
Livekit supports the distributed concept, but the api key is difficult to apply to the distributed concept. Also, it cannot be added during execution.
We are open to it, though would like to ensure it could be added in a way that does not introduce additional dependencies to the overall package. Do you have a proposal here?
how about this structure ? this is redis provider example
https://github.com/smtm-private/protocol/blob/48cdf798c23661671b2902b651452c0a788e255b/auth/provider.go#L1 https://github.com/smtm-private/livekit-server/blob/7bfa8af62ed645ba8de59fef4772aa2437efdf19/pkg/service/utils.go#L116-L145
this is changed version of wire_gen.go code. createKeyProvider is placed in main.go before https://github.com/smtm-private/livekit-server/blob/7bfa8af62ed645ba8de59fef4772aa2437efdf19/pkg/service/wire_gen.go#L15-L26
user can choice auth_type in yaml file https://github.com/smtm-private/livekit-server/blob/7bfa8af62ed645ba8de59fef4772aa2437efdf19/config-sample.yaml#L63
this approach looks good! thanks for the suggestion. It'll allow keys to be rotated without having to restart the server.. which is really neat.
I'll probably have an opinion on the exact config parameters, feel free to submit a PR and we can work off of there?
Btw, I think we could move this entirely to livekit-server. The redis dependency doesn't make a ton of sense for the protocol repo.
Btw, I think we could move this entirely to livekit-server. The redis dependency doesn't make a ton of sense for the protocol repo.
Does that mean I don't need to use the protocol repository for this task? I was wondering if that means I don't need RedisBaseKeyProvider in the protocol repository.
yea. I think it's cleaner to have the key provider in livekit server. The main purpose of protocol is to define the interfaces for others to use.
OK, as you said, if the purpose of the protocol repo is to define interfaces, you mean moving FileBasedKeyProvider and RedisBaseKeyProvider to livekit-server ?
Let's leave the file based provider in the existing repo. I think we depend on it from another package for validation.