In order to protect client from unauthorized access and malicious traffic within the application to platform, client should must implement the solution described in detail below. The described workflow will guarantee that only authorized (logged-in) user can access the widget and only through client's website. In addition to that, customer can also limit the amount of actions that are passed through to stop a DDOS attempt or to control the amount of traffic for handling peak load situations. If the below is implemented, non-logged in users would still be should notbe able to construct betslips within the Multibet widget, however widget.
The widget, and all calls to get probabilities/prices should pass through a reverse proxy which ensures that the the person requesting the price or widget is known to the bookmaker.
The "Add-to-Betslip" action would be intercepted by the authentication layer implemented within the proxy, thus preventing the risk of excess creation of markets in platform.is a client side javascript initiated event which the bookmaker website or webview should be listening to. This event is described in more detail further down this document. When the punter adds to the betslip, a call is made through the reverse proxy to create the market in the bookmaker trading platform.
To allow the widget on the web to properly authenticate the exact solution described below needs to be implemented by the bookmaker for their reverse proxy which does authentication.
Player will access client's website, which hosts an iframe. Iframe would point to the Genius
Sports Integration page endpoint (https://gsm-widgets-uat.betstream.betgenius.com/…).
Genius
Sports integration Iframe page would point to client's reverse proxy, which in turn forwards the request transparently in the background to Multibet app (www.customer.com/multibet). NB! Proxy must be located in the root path of the domain.
Webserver hosting the Multibet widget will be IP whitelisted to allow traffic only from customer's reverse proxy.
Multibet widget is then executed/rendered in player's device/browser.
Backend calls within the widget will be passing through client's proxy. Each call will be using relative paths.
If player creates a betslip ("Add-to-BetSlip") then the associated back-end call (V1: "addorupdatebetslip", V2: "savebetslip") will be intercepted to check if the user session is logged.
Sequence diagram below describes the data flow for a successful call for creating a betslip.
For a failed authentication (not authorized user, too many requests etc.), client's authentication layer should not forward the authenticated call ("addorupdatebetslip") and should instead return relevant HTTP response code (e.g. 401 Unauthorized). This will trigger a message, which will be bubbled up using postMessage. In addition to "addToBetSlip", customer should also listen to "non200Response" command in order to trigger the desired action on website. Sequence diagram below provides an overview of this user case.
The below code snippet should illustrate the additional element required to listen to the "non200response" command (this code will be part of the javascript listener which would be responsible for picking up the feedback message described here):
| Code Block | language | js
|---|
| Wiki Markup |
switch (message['command']) {
case 'addToBetslip':
break;
case 'non200Response':
break; } |
The fields in the addToBetslip looks as follows. Please consult the Sportsbook integration information to see how to use these fields.
With the above solution, client will be in control of the messaging during an authorized action and implement any desirable workflow such as:
Hide the widget
Replace the widget with a Login screen
Overlay the widget with own message(s)
Etc.