What stops a malicious user from flooding the matchmaker with requests and causing all servers to be fully allocated?
Hello jackward84,
There is a limit of one concurrent matchmaking ticket per authenticated player. A player can still join multiple different matches sequentially, but if you set your minimal player count requirement to start a match, no single malicious user will be able to allocate multiple servers.
Thanks for the reply mnachury. What stops a player from simply sending requests with fake user IDs however? If I sign in as 100 different userIds via the anonymous user option? For example I am doing this with parrelsync by fudging the user ID of the logging in client and I don’t see why a player couldn’t do this as well.
The best way to protect against this is to switch to a s2s model. You would have your own backend who does service call to create tickets on the behalf of the users. That way you can ensure their legitimacy before creating a ticket and control the value of attributes on the tickets.
You will also need to use Access Control to block player access to matchmaker service on your project. Haven’t tested it personally, but the urn should look something like this urn:ugs:matchmaker:/v2/tickets and you can have the action specific to Write if you still want to do ticket pooling on the client.
Let me know if you need more help/details, but responses might be delayed as tomorrow is a holiday at our office.
That is not the answer I was hoping to hear 
Is there a way that anonymous sign in can be disabled for the matchmaker/project/environment?
And does matchmaker check the legitimacy of player IDs that queue, ie: that a signed in Steam user ID, is in fact a legitimate steam user and not already queued? I’m not totally sure how the playerId ties in to the sign in, if at all. Though this is kind of moot if anonymous sign in cannot be disabled for MM.
Allowing user to disable anonymous auth is on UGS roadmap.
Matchmaker/UGS checks the validity of the auth token.
The only way to ensure that the content of the ticket is not modified by a malicious client to adopt the S2S approach.
UGS also provides the cloude code and cloude save services that can allow you to implement the S2S model without having to deploy your own backend.
Hi mnachury, I am looking into the s2s model a bit more seriously now and have a question.
Is it possible to create a policy that has some queues be server-to-server and other queues be player-to-matchmaker? I am guessing not, since the queue name is not part of the url, but the payload of the request.
What I am thinking is this:
- Player can only ask the matchmaker to match them in one specific queue: “lobby-queue”. This will match the player into a unity game server, but not a specific competitive game mode.
- Once in a lobby, the player can ask their current game server to queue them for other modes, such as the “1v1-queue”, “ctf-queue”. Only service accounts would have the authority to queue players for these modes, but the player can monitor the ticket status themselves.
I am thinking if policies alone are not enough to do this, then I could use the cloud code solution as a workaround.
Hi Jack, what you are suggesting is not currently possible - authentication policies per queues - but that is an interesting use case.
Specifically I am thinking of this kind of design due to the fact that the game will penalize people for not entering matches, similar to the design of World of Warcraft arenas. If you fail to enter a match, it is treated as losing that match (in addition to penalties such as “you can’t queue for x minutes”). If you enter a match and your opponent doesn’t join, it’s a free win. However without server authoritive queues, this is abusable… eg: I could queue a fake player into the match just to collect a free win against it, or impersonate another player on a matchmaking ticket to give it a loss.
To combat this, players (who are on the same team) would all need to be in the same lobby server and the game server needs to know that every player on the ticket did in fact agree to queue for the match.
The lobby queue is just a simple way to spin up servers to act as “community servers”, where players can interact with vendor NPCs, customise their gear, or just play the game casually with friends in a community driven fashion. So I don’t really care if clients are able to create matchmaking tickets for this mode on their own. Matchmaker seemed like a simple choice to have these servers available and auto-scaling. It also helps with keeping everything “server authoritive” since each individual game server can just handle talking to other services on behalf of the player.
@mathieu_mm_unity is there an update on disabling anonymous auth? It’s such and easy attack vector, I don’t understand how you guys missed this…
2 Likes