Matchmaker - Client fetching ticket status for server authoritive queue?

Unity Services
, ,
1

I am trying to write “server authoritive matchmaking” but offload the actual checking of ticket status to the client.

I set the project policy to deny write so that clients will not be able to create matchmaking tickets:

"Sid": "deny-matchmaker-access",
"Effect": "Deny",
"Action": ["Write"],
"Principal": "Player",
"Resource": "urn:ugs:matchmaker:/v2/tickets"
},```

Now I create the ticket on the game server, making a POST to /v2/matchmaker with a payload of the player IDs and queue name, and a header with the "impersonated player id". I pass that back to the client to monitor the status of the ticket ID.

Problem is that the client (even the client with the player ID that is being impersonated) cannot check the status of this ticket - 403. It requires the server/cloud code to check the status of the ticket despite this being a GET, so should not require Write access. In fact, it doesn't matter if the player has write access, it simply cannot check the status of a ticket that was created with a service account, period.

Is this what is expected when doing server authoritive queues - that the server will also need to monitor the ticket status? Is there any way around this where a client would be able to monitor the ticket status?
2

Thank you for reaching out - We will look into that.

In the mean time, you may not need to do that anymore as we have introduced the support for cloud save. As long as you configure you matchmaking rules with a key in cloud save for that player you will be able to use those data. So no need to use Cloud Code to inject server authoritative data in the ticket

3

Do you have a trace id / request id I can look for ? It should be in the header of the response you are receiving.

4

Did some testing on my side, and I was able to get a ticket created for my user via a service account.
When fetching the status of the ticket, are you using a token that has the same player id a the impersonate-user-id sent on the create request ?

5

Appreciate the quick response:

x-request-id: d8fa783e-990f-4c0d-808f-a89c4e9e765b

This returned ticket ID: fa6711c3-8018-4a61-a15b-cbbf1eb01c72

The client which is queued (and another player who is in the player list) then attempt to get the status of this ticket via the ID using

ticketStatus = await MatchmakerService.Instance.GetTicketAsync(ticketId);

This is resulting in a 403 on both clients for me. Unfortunately I’m not sure how I would get the headers from the specific MatchmakerService requests (if you need those) since those are using the SDK.

Yes - one of the clients checking has the same userId as the impersonate-user-id header, the other doesn’t. Both get 403. Is it possible to have multiple player IDs in the impersonate-player-id header? The way I am trying to work it is so one player asks the server to queue multiple players (a 2v2 in my example, but other game modes such as CTF exist too with more players), each of those players confirm and then individually monitor the resulting ticket.

6

It is normal that it does not work for the player that is not the author. We only allow the author to pull the status of their ticket. That should still be working for the player that was impersonated.

As a first step, I would suggest to log those ids (on client and cloud code side) to make sure they actually match.

On the other hand, I do see on our side the auth failures, just not the exact reason. We will look into more information on our side and into forwarding that data back to the client for debugging purposes

7

Is it possible to have multiple player IDs in the impersonate-player-id header

This is not supported at the moment. If you want an easy way to share that data between player of the same party, I suggest to use our Lobby service as it allows to share data between players,

8

I’ve figured out the issue - it was user error. I was using the header impersonated-player-id when it should have been impersonated-user-id. After correcting the header it now works without issue. Sorry for the run around!

9

No problem ! Glad you figured it out.
I would still suggest to use our Cloud Save integration with Matchmaking rules to avoid having to use Cloud Code to inject Server Authoritative data in a ticket.

10

I’m not sure how the Cloud Save MM rules can help unfortunately. For various reasons, the problem I am really trying to solve with server authoritive matchmaking is validating that the player list:

  1. Actually agreed to queue for the match
  2. Are who they say they are

I care about these things for a few reasons - mostly because I want some protection against matchmaking abuse. But without the server validating that the players on the ticket agreed to be in the player list on the ticket, I cannot penalise Player B for not joining a match if they were queued for by Player A without Player B’s permission. Nor can I really tell that Player A was the one who initiated the ticket to begin with. As far as I can tell, there needs to be some middleman that coordinates the matchmaking request and makes sure everyone involved agreed to be on that MM ticket.