Fetch Schema:
If your API provider has a million security parts you need to jump through first, or if they require parameters that can only be accessed by running other parts first then more often than not the schema fetch will fail in Wappler like this.
This is when you need to use another method to get the schema, here are a few ways.
- Directly from the API providers website, this is one from Intuit.
- This is from the “Server Connect”, “Run In Browser” output
- This is from Google Chrome, Developer Tools
What you do with this is copy the code after the data part so you do not include headers and stuff, just the returned data and paste that into Wappler like this.
Click Save, and your Schema will be available in the data pickers from Server Connect as well as when you link the action to the App Connect Client Side.
Token Handling:
Session - This is the most common method, it handles all the token stuff on your behalf, it does not need a database or storage, it refreshes on auto etc.
This is safe to use, when/if your API provider provides the refresh token on App Authorization as well as whenever you re-authorize, as the refresh token is required to get the new access token when the access token expires.
Self Maintain - This is what you need to use for API Providers like Google OAuth, as once the user connecting to your app authorizes and grants the app permission to use their Google credentials, Google will assign ONE, refresh token, thats it, you will never get this refresh token ever again unless the client removes the authorization from their account and reauthorizes the app, then it will give a different refresh token, ONCE and once only.
What this means is that if a brand new client uses your Google App and they have just granted permission, and you are on Session handling, then Wappler will store the access and refresh token in their session variable and it will work great, after the hour is up and the access token expires Wappler will use the stored refresh token and get a new access token, and the world will be wonderful. The user closes and shuts down his/her computer and goes home.
Next day they are back at work, fire up your app, and suddenly it asks for re signin to google, thats fine, it’s not a grant permissions step, or authorize an app step, they work on your app for an hour and the access token expires, but this time the session has no clue what the refresh token is, so every hour for the rest of eternity your user has to go through the re signin procedure.
If you are using “self-Maintain” and store the refresh token in a database, then you will use that for all future refreshes and the user access token expire wil no longer be an issue.
Checking whats in the Wappler Session Token (PHP)
In your page/app just add the following code
<?php
// Start the session
session_start();
// Show session variables
print_r($_SESSION);
?>
This will print out what is inside the access token and expiry token and refresh time etc. Sometimes helpful when you are not sure why your refresh token is not getting a new access token and then see the refresh token part of the session is empty, so just nice for debugging.
Last updated: