weBumpdevelopers

LESSON 03 OF 07 · RACING TUTORIAL

Wire up Connect

Use the shared browser helper and the demo’s Godot bridge.

1. Configure the game

Keep the existing scopes in config.json if you’re following the whole series. Replace client_id with your approved ID and redirect_uri with your exact callback. Keep api_origin as https://api.webump.app and approval_display as auto.

In web/shell.html, change HOST_ORIGIN to your hosting page’s origin, such as https://your-game.example, with no path or trailing slash. Keep its origin/source validation and request IDs.

2. Put the host files on your website

Download the Godot host example. It includes a small hosting page, the current JavaScript SDK, and the generic callback prompt. It works with this demo’s export shell and autoload; it does not modify an arbitrary Godot game automatically.

your website/
  index.html
  host.js
  host.css
  webump.js
  callback.html
  callback.js
  callback.css

Edit CLIENT_ID, CALLBACK_URL, FRAME_URL and SCOPES at the top of host.js. The client, callback and scopes must match the game configuration and reviewed project. The frame URL is the exact URL of your exported game, including any version query.

The host installs attachGameFrame before loading the iframe. That helper owns PKCE and callback listening, checks the frame’s origin and identity, and sends tokens only to the initiating frame. The existing Godot shell passes them into WeBumpAPI; you do not need to implement another OAuth flow.

3. Keep the callback separate

Serve callback.html at the exact registered URL on the host’s origin. It relays approval to the original tab and says “Go back to your game.” It never loads another game. Keep the original game tab open in the same browser.

Configure callback response headers Cache-Control: no-store and Referrer-Policy: no-referrer. Keep it out of service-worker caches, analytics and query-string access logs. The download’s README gives a restrictive callback CSP and explains the separate allowances needed by the game and host.

4. Use the existing button and signals

The demo already wires its button to WeBumpAPI.connect_player(). For a different Godot screen, this is the minimal connection wiring; the screen must also render the approval UI from approval_started, as the existing title screen does.

extends Control

func _ready() -> void:
    WeBumpAPI.auth_succeeded.connect(_connected)
    WeBumpAPI.auth_failed.connect(_failed)

func _on_connect_pressed() -> void:
    WeBumpAPI.connect_player()

func _connected(profile: Dictionary, is_mock: bool) -> void:
    $Status.text = str(profile.get("display_name", "Player"))

func _failed(message: String) -> void:
    $Status.text = message

Add a Label named Status and connect your button’s pressed signal to _on_connect_pressed if trying that snippet. Do not paste it over the demo’s complete title screen. Use the standard Connect control and assets when building your own UI.

Checkpoint

After exporting and hosting (lesson 7), an iPhone/iPad on your host uses app approval and the callback, with no matching code. A computer displays a QR and short code for approval on an iPhone. Cancel returns to a fresh Connect state. Direct local or GitHub Pages exports without the host bridge intentionally use device approval.

What if I’m not using Godot or an iframe?

Use connectBrowser directly in a website. Use the Swift SDK for native callback/device integration, or the documented public-client endpoints in another engine. See the browser quickstart. No developer backend is required for these flows.

Why can a local copy connect?

An approved project plus player approval grants scoped access. Public configuration alone grants none. The callback protects code delivery; later API requests use the player’s token. Device approval deliberately supports local games and other devices. It does not attest an official game binary. Never replace the callback with code-returning status polling; /oauth/pending is status-only.