Auth Page Setup
Optional Auth & Registration Page
MetaFab offers an optional, out of the box, ready to go and fully brandable solution to handle your player authentication, registration and wallet connection flows. This system can be embedded as a web page or through a redirect flow.
This system was built to help you fast track your player auth and onboarding flows. It is completely optional and provided entirely for added convenience.
You can check out an unbranded demo of our auth page here.
You can fully brand the look and feel of your game's auth page. This can be done quickly using the update game API endpoint.
Updatable branding parameters for your game that can be set through the update game endpoint are:
name: This is the name of your game shown on the page's form.
iconImageBase64: This is the image used for the circular icon at the top your page's form. This parameter is set as a base64 representation of the image you want to use. You can use tools like https://www.base64-image.de/ to convert your image to it's base64 version, such as
coverImageBase64: This is the background image used for your page. This parameter is set as a base64 representation of the image you want to use. You can use tools like https://www.base64-image.de/ to convert your image to it's base64 version, such as
primaryColorHex: The hex color (#05B1A3 for example) to use for the buttons on your auth page.
Setup & Configuration
You can configure your auth page for a number of different use cases. These include player login, registration and external wallet connections.
All default usages of the MetaFab's configurable auth page are set on the base url:
https://connect.trymetafab.com. We also support login flows through your game's custom domain or subdomain.
Usage configuration is done by setting query parameters. These query parameters are appended to the base auth page url of
https://connect.trymetafab.com. For example, a valid configured auth page URL is: https://connect.trymetafab.com/?chain=MATIC&game=898d9a17-9a9b-45a2-9ab9-3cd4300ef5f9&redirectUri=http://localhost
See the list of configurable query parameters and their explanations below.
|Query Parameter||Explanation||Valid Values|
|This tells the auth page what game to login, register or connect your player's wallets for.||Any valid game |
|The auth page flow you want to push your users through. Such as login, registration or wallet connection.|
|The blockchain the an external wallet should be connected for. This is only relevant if using the ||A valid chain, such as: |
|A supported redirect uri allowed for your game. You can set allowed redirect URI's through this endpoint.|
Including this parameter will redirect the player to this uri after going through the specified flow. The redirect uri will receive the player's
Excluding this parameter will set the logged in player's
|A valid redirect uri or base uri for your game. For example, |
Custom Domain Support
If you'd like to route your player login through a custom domain or subdomain instead of
https://connect.trymetafab.com, please reach out to our team on Discord to configure this.
Example Flows & Implementation Patterns
Depending on your games needs, here's a few possible patterns you may choose to integrate your auth page through.
Redirect patterns are common for web-based games or UI's where your players need to be redirected to some page on your game's website, or perhaps a settings page on the web for your game.
redirectUri, your game may choose to link the "Register" or "Login" button from your game's website to the
https://connect.trymetafab.com?... auth flow page. From there, your player would be able to login or register. After successfully logging in or registering, the player would be redirected to the
redirectUri you set in the auth page's query parameters.
This redirect uri will have the authenticated player's
id. For example, a redirect uri may be
https://mygame.com/game and the resulting redirect will become
https://mygame.com/game#accessToken=PLAYER_ACCESS_TOKEN&walletDecryptKey=PLAYER_WALLET_DECRYPT_KEY&id=PLAYER_ID. From here, your game's webpage logic can grab the player
id from the fragment (#) url parameters and perform any final login/authentication logic needed for your game.
The embed pattern is intended for mobile apps, native games, or any non-web implementations.
For example, you may choose to build a mobile app or desktop game and use our auth page for login, registration or connection of your player's external wallets.
You can use the embed pattern by excluding the
redirectUri from the auth page's query parameters. This allows you to do an in-app or in-game web browser/modal window that opens your MetaFab auth page. Your player would complete the specified flow (login, registration or wallet connection) and once finished the player's
id will be set and update the auth page's URL. An example final page URL after a player completes the flow may look like
You can use a url change listener for your in-app or in-game browser modal and wait for the #
id= fragment properties to be set on the url. Once set, you can extract the player's
id and perform any additional auth logic for your game from there and automatically close the browser modal/pop-up.
External Wallet Connection Pattern
The external wallet connection pattern is to allow your players to connect their external wallet to your game, and interact, transact and play/earn through your game with all interactions automatically & frictionlessly happening to/from their connected external wallet.
An example implementation of this flow may be having a
Connect Wallet button in an existing player's settings page. Upon clicking, you would redirect them to your auth page with the flow set to
Alternatively, you may want to offer player registration and force players to have to connect their wallet to complete registration for your game. To do this, you'd simply set the flow query parameter to
registerConnect and implement either the
Redirect Pattern or
Embed Pattern from there.
Consideration: After External Wallet Connection
After your player has connected an external wallet, if you use their player object's
walletproperty locally, be sure to update any existing local or cached player object such that their associated
walletproperty for that object also reflects their newly connected wallet address.
Updated 4 months ago