This repository contains sample code for building a reverse proxy that enables web socket connections over https
to PlayFab hosted multiplayer servers. This repository is not an official solution, but a starting point for developers who intend to deploy their multiplayer game to a browser.
Developers that intend to deploy their multiplayer game on the web face a problem when server connections originate from a https://
domain. PlayFab hosted game servers are typically hosted from a subdomain of azure.com
. For security reasons, PlayFab cannot issue SSL certificates to developers to use for azure.com
.
Browser security policies require that web socket connections originating from https://
are created with a secure connection (web socket over https or wss://
).
A reverse proxy can be used to forward requests from a https://
domain to a PlayFab hosted game server, without the need for an SSL certificate on the game server.
Consider the following browser client flow
- The client retrieves the session ID for an active server. This is typically taken from the result of a call to Request Multiplayer Server.
- Your game's browser client initiates a connection with the server details
- If you owned the domain
my-domain.com
the request would bewss://my-domain.com/{sessionId}
- If you owned the domain
- The reverse proxy looks up the server details and forwards the request to the server's fully qualified domain name - a subdomain of
azure.com
.
The previous flow could be modified to use the Matchmaking API. Session ID would be replaced with the the match ID and queue name returned from Create Matchmaking Ticket.
This Dockerfile creates a HTTP server that handles requests at /{sessionId}/{**forwardPath}
. Requests are proxied to a game server in the Active
state that was requested with Request Multiplayer Server.
The docker application is intended to be deployed as a web service that is separate from your game server. Game servers deployed as HTTP hosts run into the same issue that the repository MultiplayerServerSecureWebsocket mentions as a problem for games hosted on a https domain - you can't generate a SSL certificate for the fully qualified azure.com domain name of each server session.
Azure App Service is an "off the shelf" solution for the docker application. Linux and Windows should be supported since .NET Core is cross platform.
When your web client configures a web socket connection i.e. ConnectEndpoint with Unity or WebSocket in client side JavaScript, you'll use the fully qualified domain name from your deployed web service.
For example, if you created an Azure App Service, the full qualified domain name would be something like https://myreverseproxy.azurewebsites.net/{sessionId}/
While this is not an official solution, the best channel to discuss this respository or receive help is to use the Discussion section.