In order to protect client from unauthorized access and malicious traffic within the application to platform, client should 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 able to construct betslips within the Betbuilder widget, however "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.
- Punter will access client's website, which hosts an iframe. Iframe would point to the Genius Sports Integration page endpoint (cdn.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 Betbuilder app (client{env}.sportcastlive.com/). NB! Proxy must be located in the root path of the domain.
- Webserver hosting the Betbuilder widget will be IP whitelisted to allow traffic only from customer's reverse proxy.
- Betbuilder widget is then executed/rendered in punter's device/browser.
- Backend calls within the widget will be passing through client's proxy. Each call will be using relative paths.
- If punter 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):
switch (message['command']) {
case 'addToBetslip':
break;
case 'non200Response':
break; }
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.