Can I use runtime.RUNTIME_CTX_VARS to pass value to server?

Local Setup
1

I want to pass an app version to nakama server in every connection.
I tried to store it in ISession.

session.Vars.Add("AppVersion", "this is test value");

and call rpc like this.

var apiRpc = await client.RpcAsync(session, "GetPlayerInfoRPC", request);

in gomodules.
I tried to get it via context.

vars, ok := ctx.Value(runtime.RUNTIME_CTX_VARS).(map[string]string)

But ok is always false.

What is the Vars for?
And What is the best way to pass custom values in all connections?

2

Hey @opus_kojiro. We’ve not caught up with documentation yet but a quick explanation on what session variables are for will help you with your Nakama development.

Session variables allow server side code to embed additional key/value pairs into the session token generated by the game server. This enables the session token to act like an edge cache for information that won’t change until the next authentication (or re-authentication) happens.

There’s two ways to set session variables:

  1. You can send them from the game client when the authenticate request is made to the server. For example with the Unity client sdk:

    var id = "some-unique-identifier";
string username = null;
var create = true;
var vars = new Dictionary<string, string> {{"key", "value"}};
var session = await _client.AuthenticateCustomAsync(id, username, create, vars);

  2. Set the session variables on the server-side with a before hook on the authenticate feature you use:

    func beforeAuthenticateCustom(ctx context.Context, logger runtime.Logger, db *sql.DB, nk runtime.NakamaModule, in *api.AuthenticateCustomRequest) (*api.AuthenticateCustomRequest, error) {
    in.GetAccount().Vars = map[string]string{"key": "value"}
    return in, nil
}

When you’ve set some session variables you’ll be able to access them from the session object as you’ve found in the Unity client sdk. You can also obtain them server side as you’ve shown via the context object with either Go or Lua scripts.

The use case you have which is to check whether the game client version is within some range is an example of a good reason we introduced the concept of session variables. Hope this helps. :slight_smile:

1 Like
3

Thanks!
Worked fine!

1 Like
4

Hi @novabyte! And there’s no way to set additional vars / update vars once the session has been created, is that correct?

5

@gupta-vaibhav At the moment these values are set at server startup and don’t act like a live cache for the values. I’m open to potential use cases for it though. What did you have in mind?

6

@novabyte at server startup? or did you mean session startup, just to be sure.

The concern that I had was that in the before hook, the session hasn’t yet been authenticated. I don’t even have the user id at that point (although I can get it based on the custom_id, but that would be an additional db query just to set the session vars).

So technically setting session variables even before the session has been created didn’t feel right to me personally. Ideally, I would have created them in the after hook.

Besides, other session vars such as ‘paid user’, could change mid session. For most practical cases, we could wait until the next session for the var to be updated, but the right implementation would be to set it right away.

7

at server startup? or did you mean session startup, just to be sure

Yes sorry I forgot which thread I had answered. :slight_smile:

So technically setting session variables even before the session has been created didn’t feel right to me personally. Ideally, I would have created them in the after hook.

I think the problem with the after hook approach is that the lifecycle of after hooks are executed after the response has already gone on the socket. This behaviour could not be changed as it’d break the expectations of many games which use Nakama.

Besides, other session vars such as ‘paid user’, could change mid session.

You can easily update the session token with a custom RPC function and swap it out in the game client (though it would require you to reconnect the socket for those vars to be available). All the functions needed to modify the session token are available in the server runtime.

8

Yes, I do understand the limitation of the after hook and that’s a very valid point. For updating session token mid-session sounds like a reasonable work-around for infrequent cases, like the one I mentioned.

If I do run into an issue which is not addressed through this, will ping you again. I don’t have such a situation currently, and the question was primarily for a sound understanding of the feature.

Thanks! The feature request for session vars was opened by me only. Glad to see it having been incorporated. I am looking forward to using it extensively now. :+1: :grinning:

9

@gupta-vaibhav Ok great. We don’t have docs for the feature yet so I’ll open an issue on the docs tracker to add details for it.

10

On that note, once I have used session vars and understood them well, I could also submit a PR for updating the docs.

1 Like