Again just spit-balling with code here, but check ...

# kotlinx-rpc

[darkmoon_uk]

Again just spit-balling with code here, but check this out:

authenticate(JWT_AUTH_NAME) {
  rpc(AUTHENTICATED_API_PATH) {
    val currentCall: ApplicationCall = call
    val principal = currentCall.principal<JWTPrincipal>() // Capture the principal
    rpcConfig {
      serialization {
        json()
      }
    }

    registerService<UserService> { coroutineContext ->
      UserServiceImpl(principal, coroutineContext) // Pass principal into service - note this assumes the Service factory will be invoked for each new user(?)
    }
  }
}

[S.]

the registerService function says Service of any type should be unique on the server, but RPCServer does not specify the actual retention policy. I'm not sure whether this means only one single implementation or only one single registered service, I would assume the latter

[S.]

I'm considering passing the token as a parameter in each rpc function call instead of a header but it's not pretty either

[darkmoon_uk]

Yeah feels like this is a critical part of RPC design, being able to relate a given 'session' with a service. Passing tokens as RPC parameter sounds like defeat to me TBH, it would be a last act of desperation! I am still wondering if bundling the tokens in the Coroutine Context is a viable hack... since there should be a Job per 'session'?

[S.]

I think the passed coroutine context is long lived though for the entire service, so the same issue as above

[S.]

it certainly is desperation, thought at least it makes it obvious which requests require auth 😅

[S.]

going through the GH issues there is a plugin system similar to ktors planned https://github.com/Kotlin/kotlinx-rpc/issues/150. if you get any kind of hooks where you can add an additional parameter map to each function it would be great. possibly also for other headers

[darkmoon_uk]

Thanks, I will have to give it some empirical exploration as well; haven't given up on finding a way just yet, but it does look tricky until there's more first-class support...

[S.]

for example https://github.com/ExpediaGroup/graphql-kotlin has a DataFetchingEnvironment which you can add to your functions to use internally but is basically transient for the actual rpc function signature