Authenticating User-Session Using a Proxy Service
- Raiko Pajur
Analytics
In order to protect customer from unauthorized access and malicious traffic within the application to platform, client 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. If the below is implemented, non-logged in users should not be able to construct betslips within the Multibet Widget.
All Widget calls should pass through a reverse proxy which ensures that the the person requesting the price is known to the customer.
To allow the Widget on the web to properly authenticate the exact solution described below needs to be implemented by the customer for their reverse proxy which does authentication.
Player will access customer’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 customer'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.
Sequence diagram below describes the data flow for a successful call for adding a multibet to customer’s betslip.
For a failed authentication (not authorized user, too many requests etc.), client's authentication layer should not forward the authenticated call 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.