Network access and firewalls

This page is for the IT team that opens Maketools on the company network: proxy, firewall, URL filtering, managed browsers and LMS.

Addresses to allow

Everything goes over HTTPS (port 443). Allow these two addresses, or simply *.maketools.ai:

Why two addresses. Games run inside an isolated (sandboxed) frame, served from an address separate from the site, which sets no cookie and is wired to no API: a game can neither read the player's session, nor call the API, nor change the interface (see the trust center). If play.maketools.ai is blocked, the site opens but the game does not load.

If your proxy inspects encrypted traffic, it must pass the security headers of the responses (Content-Security-Policy in particular) through unchanged: the game frame only runs with them.

What Maketools does not load

No third-party script, font or tracker: fonts are served by Maketools, and the site's security policy refuses any script from elsewhere. Other addresses only come into play if you use the matching feature:

Emails (sign-in codes, invitations, notifications) are sent from an address on a subdomain of maketools.ai: if your mail filter works from an allow list, allow senders from *.maketools.ai.

Cookies and storage

The site only sets strictly necessary first-party cookies on maketools.ai (session, sign-in security), and keeps a few preferences in the browser (language, theme, chosen organisation). Games, served by play.maketools.ai, set no cookie and write nothing to the browser. The detail is in the privacy policy.

A game shown inside an LMS page also uses a partitioned cookie, which the browser stores under the LMS site: it is what spares learners from signing in again at every launch. A browser policy that refuses partitioned cookies prevents this mode; the "new window" mode then remains available (see LMS integration).

Pop-ups

Allow pop-ups for your LMS: a learner signs in to a game shown in the LMS through a small window of the site, and a window-mode package opens the game in a separate window.

Games shown inside your LMS

• Declare in Maketools every address of your LMS that shows the game (the LMS interface and, if different, the address that serves the SCORM content): anywhere else, the game page refuses to be framed.
• If the LMS isolates SCORM content in a sandbox frame, that frame keeps allow-scripts, allow-same-origin, allow-popups and allow-popups-to-escape-sandbox, and delegates allow="autoplay; fullscreen" for full screen.

The step-by-step is in LMS integration.

Calls from Maketools to your systems

Two features make Maketools servers call yours:

• OpenID Connect SSO (sign-in code exchange, signing keys);
• the xAPI connector (statements sent to your LRS).

Maketools servers have no fixed IP address: an identity provider or an LRS hosted on your premises that only accepts allow-listed addresses will refuse these calls. For sign-in, choose SAML instead, which goes through the user's browser and never calls your provider (see SSO). For xAPI, the LRS must be reachable from the Internet over HTTPS. Online services (Entra ID, Okta, Google Workspace, hosted LRSs) are not affected.

Browsers

Maketools works in recent versions of Chrome, Edge, Firefox and Safari, on desktop and mobile, with JavaScript enabled. For a game shown inside an LMS, see the checked browsers.

Checklist

• maketools.ai and play.maketools.ai (or *.maketools.ai) allowed over HTTPS
• Security headers left unchanged by the proxy
• Pop-ups allowed for the LMS
• Partitioned cookies accepted by managed browsers (embedded mode in the LMS)
• LMS addresses declared in Maketools (Reports › LMS connector)
• Senders from *.maketools.ai accepted by your mail system
• SSO through SAML if your identity provider filters IP addresses