Session Endpoint
The session endpoint is for the operator's own frontend to call in order to generate a random temporary auth token to inject into the BetLink frontend, which it will pass to the BetLink backend and subsequently the Auth endpoint will be called as defined in the 'Auth Endpoint' section. Authentication must be completed before a BetLink user can place any bets.
If a user is logged in at the point of BetLink launch, the operator might optionally wish to generate the user session as part of other configuration calls to the operator backend during launch and skip this step. However, a session endpoint will still be required for the authentication route to be completed if BetLink is launched for a non-logged in user, who then wishes to place bets (see front end documentation for how these routes might work best for the operator's specific frontend requirements).
Whether the session endpoint is called directly or the user session is created during some other backend launch process, the operator's backend should create a stateful session for that specific user. That session should contain the userId, the temporary token, an expiry date of the temporary token (recommended to be 10 seconds) and empty spaces for a session token and a session token expiry date. Below is an example/suggestion of how a row in a user_session DB table might look. The session token and the session token expiry fields will be populated as described in the Auth Endpoint section.
It is at the discretion of the operator to design the session endpoint as they see fit. However, there are some strong recommendations:
The session endpoint should only return a temporary token for logged in users.
The session endpoint should never return anything other than the temporary token.
The session endpoint should create a new session every time it's called for a logged in user.
User Session Table Schema Suggestion And Population Upon Session Creation
12345
extUserId
d26ae5ed-ccbf-427c-b027-264de1700734
1664560297000
PENDING_AUTH
Last updated