Overview
In all our examples at https://near.dev, we ask that the end user log in with NEAR Wallet before interacting with the dApp. Those type of examples explore the use case where an end user wishes to create a function-call access key on their own account.
This ticket explores the use case where a dApp (with a backend, not purely frontend) allows users to enter an "invite code" into an input element and get a function-call access key created from the contract account instead.
[ ] Express app with database access (If needed, lean on tutorials like this to get started with an ExpressJS app that connects to either a MongoDB database or MySQL database. This is a simple proof of concept, we do not need full CRUD (create read update delete) functionality.
[ ] Create a hardcoded list of, say, 6 "invite codes" in a simple Mongo database. Make a "backup" that will be included in the example repository, and README instructions on how to "restore" this database as part of the instructions. This might be a useful guide.
[ ] Create a simple frontend that asks the user for an invite code. The end user will enter their invite code into an input, then click a button. Upon clicking that button, the frontend will make a request to the ExpressJS server using a "read" route. (AKA a GET request)
[ ] Use near-api-js to create a new, randomized keypair of the type BrowserLocalStorageKeyStore when the page loads. Verify that the private key exists by looking in the Developer Tools » Application » Local Storage. Store the public key at window.hahatemporary. Once this item is complete, let's move the key creation logic into the onClick of the button. (We will be sending two arguments to the backend: the invite code the user entered and the public key we just created)
[ ] In the ExpressJS backend (inside the GET route or a function called from that route) the database will be queried for that invite code. If the invite code doesn't exist, it'll return some value indicating an invalid invite code. If it succeeds, then it will load a full access key using near-api-js, create a function-call access key using the public key passed in from the frontend, then send a 200 "everything worked" response. At this time, the end user can interact with whatever contract (say, status message) without having to login. Since they don't have to login, this also means they're not using their own gas. They're sending transactions using the gas of the contract itself. This is the important takeaway for this demo.
[ ] Include help text explaining to the user what's happening. Something like "This is a demonstration of having a private key created on behalf of a user, allowing folks who don't have a NEAR account to interact with a contract. Gas used for sending transactions come from the dApp contract… blah blah blah"
Overview In all our examples at https://near.dev, we ask that the end user log in with NEAR Wallet before interacting with the dApp. Those type of examples explore the use case where an end user wishes to create a function-call access key on their own account.
This ticket explores the use case where a dApp (with a backend, not purely frontend) allows users to enter an "invite code" into an input element and get a function-call access key created from the contract account instead.
GET
request)near-api-js
to create a new, randomized keypair of the type BrowserLocalStorageKeyStore when the page loads. Verify that the private key exists by looking in the Developer Tools » Application » Local Storage. Store the public key atwindow.hahatemporary
. Once this item is complete, let's move the key creation logic into the onClick of the button. (We will be sending two arguments to the backend: the invite code the user entered and the public key we just created)GET
route or a function called from that route) the database will be queried for that invite code. If the invite code doesn't exist, it'll return some value indicating an invalid invite code. If it succeeds, then it will load a full access key using near-api-js, create a function-call access key using the public key passed in from the frontend, then send a 200 "everything worked" response. At this time, the end user can interact with whatever contract (say, status message) without having to login. Since they don't have to login, this also means they're not using their own gas. They're sending transactions using the gas of the contract itself. This is the important takeaway for this demo.