Enable authentication

Since our app will require authentication we need to enable authentication.

To do this first create a new page and call it Login. This is going to be our initial page.

Then select Direct third party authentication and click OK

This will create another new page called Log in. Since we've created our own login page select it from the dropdown as the Initial view. If you prefer you can also use this default page that AppGyver creates but for this tutorial we're creating our own login page.

Create data resources

In the main navigation bar click on DATA and then ADD DATA RESOURCE.

SignUp data resource

In the newly created resource under BASE complete the info like below. Most importantly replace the Resource URL with your Bubble signup workflow URL. If you've created a new Bubble app and using the default domain then simply replace the app name part of the URL(highlighted in yellow here). Since the signup endpoint doesn't require authentication we wont add an header here.

Now click on the CREATE RECORD (POST) to setup the post request.

All Bubble workflow endpoints are POST requests so in AppGyver you will always use the CREATE RECORD (POST) to setup the request.

Check the box Method enabled.

Leave the Relative path field empty as our base contains the full path.

Under the Responses key path enter response. The reason why we enter response in the here is that the structure of the response object from bubble looks like this. So specifying response here will allow us to only that value without the status value. If you want to have the whole object you can leave this field empty (but to follow along this tutorial set it up as shown).

{
  "status": "string",
  "response": {
    "user_id": "string",
    "token": "string",
    "expires": 0
  }
}

We now need to create a request scheme for our endpoint call. Click on the SCHEMA tab and then ADD PROPERTY to add the three parameters for our signup call.

Note the names should match exactly as defined in the Bubble workflow endpoint.

To test the newly created request and generate a response schema, click on the TEST tab and enter some example values. Click on RUN TEST and you should receive a Status: OK response with the returned response data like below.

Click on SET SCHEMA FROM RESPONSE to create a schema based on the test response. You will be taking to the SCHEMA page and see the request and response schema. Now you're ready to use this data resource in your app.

Login data resource

The login data resource setup is very similar to the signup with the only difference being that the request parameters are only email and password.

So here is the setup.

As can be seen in the response, the expires value is the number of seconds that this token is valid for until the user logs out. Here it is 31536000 seconds, i.e. 1yr. This means after year this token will expire and becomes invalid.

To keep things simple in this tutorial we didn't handle token expiration. But in your production app you should have some logic to handle it. There are a number of ways to do this. You can calculate the date it expires and store this on device. So that anytime the app launches you can compare it to the current date. The downside is that if the user changes date on their phone it can cause some error in your logic. Alternatively you can always make a test call with the current token when the app launches and if the call fails with the token expire message you redirect the user to the login screen to log in again to get a new token. Note that Bubble currently doesn't refresh tokens.

User data resource

The user data resource unlike the signup and login endpoints requires authentication so we will add the Authorization key to the header as shown below.

In this tutorial we will only be retrieving a user's information so will only setup the GET RECORD (GET) call. To retrieve a user we need to pass the user's id as a url parameter.

Click on the GET RECORD (GET) page. In the Relative path enter /{id}.

Under URL placeholders create the id key as shown below.

The GET user endpoint doesn't require any body so we won't define any request schema.

Test the call and generate a schema from the response. In the Authorization field enter Bearer <token> (replace <token> with the token from the login call). In the id field enter the user id obtained from the login call.

Click on SET SCHEMA FROM RESPONSE to create the response schema.

Logout data resource

The logout endpoint is a Bubble workflow endpoint just like the signup and login but it requires an Authorization header like in the User endpoints.

Last updated