zyphr 0.1.38 → 0.1.40

data/lib/zyphr/api/auth_registration_api.rb

@@ -224,7 +224,7 @@ module Zyphr
     end
 
     # Sign in with Apple Game Center
-    # Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the modern scoped `playerId` (gamePlayerID).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit's `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player's `gamePlayerID` and the app's bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer's own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
+    # Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the player's `teamPlayerID` (the id GameKit signs the assertion over).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit's `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player's `teamPlayerID` (NOT `gamePlayerID`) and the app's bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer's own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
     # @param sign_in_with_game_center_request [SignInWithGameCenterRequest] 
     # @param [Hash] opts the optional parameters
     # @return [AuthResultResponse]
@@ -234,7 +234,7 @@ module Zyphr
     end
 
     # Sign in with Apple Game Center
-    # Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the modern scoped `playerId` (gamePlayerID).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit's `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player's `gamePlayerID` and the app's bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer's own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
+    # Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the player's `teamPlayerID` (the id GameKit signs the assertion over).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit's `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player's `teamPlayerID` (NOT `gamePlayerID`) and the app's bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer's own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
     # @param sign_in_with_game_center_request [SignInWithGameCenterRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(AuthResultResponse, Integer, Hash)>] AuthResultResponse data, response status code and response headers
@@ -290,5 +290,73 @@ module Zyphr
       end
       return data, status_code, headers
     end
+
+    # Sign in with Google Play Games Services
+    # Exchange a Google Play Games Services (GPGS) **server auth code** for a Zyphr end-user session. Unlike Game Center (which submits an Apple-signed assertion), GPGS is verified by Google: Zyphr exchanges the single-use server auth code at Google's OAuth2 token endpoint, then calls the Play Games REST API (`players/me`) server-side to obtain the trusted, tamper-proof `playerId`. The user is provisioned-or-looked-up on that server-fetched `playerId` and tokens are minted.  ## Producing the server auth code (Integration)  The server auth code is obtained **on-device by the Android app** — there is no server-side way to mint it. The app calls `GamesSignInClient.requestServerSideAccess(serverClientId, …)` using the Google Cloud **web (server) client id** configured for the game, which returns a single-use auth code string. Submit that string here as `serverAuthCode`.  The **backend-relayed** shape is the common one: the app forwards the auth code to the customer's own backend, which relays it to this endpoint; the app never holds Zyphr keys.  ## Security  The `playerId` is derived **only** from Zyphr's own server-side call to Google after the token exchange — a client-supplied player id is never accepted or trusted. On any verification failure the response is a single opaque `401` `invalid_auth_code`; the specific control that failed is never disclosed. 
+    # @param sign_in_with_google_play_games_request [SignInWithGooglePlayGamesRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [AuthResultResponse]
+    def sign_in_with_google_play_games(sign_in_with_google_play_games_request, opts = {})
+      data, _status_code, _headers = sign_in_with_google_play_games_with_http_info(sign_in_with_google_play_games_request, opts)
+      data
+    end
+
+    # Sign in with Google Play Games Services
+    # Exchange a Google Play Games Services (GPGS) **server auth code** for a Zyphr end-user session. Unlike Game Center (which submits an Apple-signed assertion), GPGS is verified by Google: Zyphr exchanges the single-use server auth code at Google&#39;s OAuth2 token endpoint, then calls the Play Games REST API (&#x60;players/me&#x60;) server-side to obtain the trusted, tamper-proof &#x60;playerId&#x60;. The user is provisioned-or-looked-up on that server-fetched &#x60;playerId&#x60; and tokens are minted.  ## Producing the server auth code (Integration)  The server auth code is obtained **on-device by the Android app** — there is no server-side way to mint it. The app calls &#x60;GamesSignInClient.requestServerSideAccess(serverClientId, …)&#x60; using the Google Cloud **web (server) client id** configured for the game, which returns a single-use auth code string. Submit that string here as &#x60;serverAuthCode&#x60;.  The **backend-relayed** shape is the common one: the app forwards the auth code to the customer&#39;s own backend, which relays it to this endpoint; the app never holds Zyphr keys.  ## Security  The &#x60;playerId&#x60; is derived **only** from Zyphr&#39;s own server-side call to Google after the token exchange — a client-supplied player id is never accepted or trusted. On any verification failure the response is a single opaque &#x60;401&#x60; &#x60;invalid_auth_code&#x60;; the specific control that failed is never disclosed. 
+    # @param sign_in_with_google_play_games_request [SignInWithGooglePlayGamesRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [Array<(AuthResultResponse, Integer, Hash)>] AuthResultResponse data, response status code and response headers
+    def sign_in_with_google_play_games_with_http_info(sign_in_with_google_play_games_request, opts = {})
+      if @api_client.config.debugging
+        @api_client.config.logger.debug 'Calling API: AuthRegistrationApi.sign_in_with_google_play_games ...'
+      end
+      # verify the required parameter 'sign_in_with_google_play_games_request' is set
+      if @api_client.config.client_side_validation && sign_in_with_google_play_games_request.nil?
+        fail ArgumentError, "Missing the required parameter 'sign_in_with_google_play_games_request' when calling AuthRegistrationApi.sign_in_with_google_play_games"
+      end
+      # resource path
+      local_var_path = '/auth/google-play-games'
+
+      # query parameters
+      query_params = opts[:query_params] || {}
+
+      # header parameters
+      header_params = opts[:header_params] || {}
+      # HTTP header 'Accept' (if needed)
+      header_params['Accept'] = @api_client.select_header_accept(['application/json']) unless header_params['Accept']
+      # HTTP header 'Content-Type'
+      content_type = @api_client.select_header_content_type(['application/json'])
+      if !content_type.nil?
+          header_params['Content-Type'] = content_type
+      end
+
+      # form parameters
+      form_params = opts[:form_params] || {}
+
+      # http body (model)
+      post_body = opts[:debug_body] || @api_client.object_to_http_body(sign_in_with_google_play_games_request)
+
+      # return_type
+      return_type = opts[:debug_return_type] || 'AuthResultResponse'
+
+      # auth_names
+      auth_names = opts[:debug_auth_names] || ['ApplicationPublicKey']
+
+      new_options = opts.merge(
+        :operation => :"AuthRegistrationApi.sign_in_with_google_play_games",
+        :header_params => header_params,
+        :query_params => query_params,
+        :form_params => form_params,
+        :body => post_body,
+        :auth_names => auth_names,
+        :return_type => return_type
+      )
+
+      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
+      if @api_client.config.debugging
+        @api_client.config.logger.debug "API called: AuthRegistrationApi#sign_in_with_google_play_games\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
+      end
+      return data, status_code, headers
+    end
   end
 end