Sessions
In general terms, a “session” is a period during which a user is authenticated with a system.
In LayerG, the session is represented with a client-side object that proves the client was authenticated when accessing server functions.
Session duration can be set with the token_expiry_sec property in the configuration. It is recommended to set a session duration of about 2 to 3 times the length of your game’s average play session.
Sessions expire and become invalid after this set period. A refresh token is provided when the client authenticates, enabling you to obtain new auth tokens for as long as the refresh token remains valid. When the refresh token expires, you’ll need to reauthenticate with the server to get a new session.
Session details
You can access a user’s id, name, and whether their session is expired using the following code:
Session refresh
You can optionally provide new session variable values when refreshing a session. These new values will replace any session variables currently stored in the session object.
Session logout
It is good security practice to enable users to logout of an active session. This can be used to prevent unauthorized access by another person when using a shared device, for example.
Logging out of a user’s session invalidates their authentication and refresh tokens, but does not disconnect their open socket connections. This can be accomplished via the server-side sessionDisconnect function. See the corresponding function reference.
Session variables
Session variables allow clients and 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 as an edge cache, with the information available as long as the session remains active.
These can be used to implement different features and tools, such as analytics, referral bonuses, or rewards programs.
You can optionally provide new session variable values when refreshing a session. These new values will replace any session variables currently stored in the session object.
Setting with client
To set the variables in the client’s request for authentication use:
This example shows setting session variables with Email Authentication, but this feature is available for all of the other authentication options and in all client libraries.
Setting with server
Session variables may be set by the server, but only in the before authentication hooks.
Accessing with server
Once set, session variables become read-only and may be accessed in any server hook. The only way to change or delete a session variable is through forcing the client to authenticate again.
Related Pages