Authorization workflow settings
Authorization settings include four steps. Some steps are unavailable using a special combination of Type and Method. Each step allows you to save Authorization and return to settings later. When Authorization is completed, each step also can be edited.
Enter an Authorization name, type and method at this step. Using the oAuth method, set up additional fields.
Type and Method cannot be edited when Authorization is completed. In case of incorrect type or method, create the Authorization again.
This step appears for Custom type only.
Fields required for Authorization are created, which will be requested from the end user at the time of creating app connection.
All created fields will be displayed for filling, the values of these fields will be saved within the connection.
The fields themselves can be used as dynamic variables in the next steps, substituting them in HTTP requests.
Creating a field, fill in the following values:
Field code: internal ID field
Name in English: name will be displayed to the end-user in Albato English interface
Name in Russian: name will be displayed to the end-user in Albato Russian interface
Hint in English: text will be shown under the required field as an explanation. Displayed in Albato English interface.
Hint in Russian: text will be shown under the required field as an explanation. Displayed in Albato Russian interface.
Type: field type is selected. There are: string – a regular input string; integer – allows to store only numbers; email – allows to validate email before saving; password – entered data will be hidden with dots; subdomain - the end-user will see a static prefix and postfix; boolean - checkbox field.
All fields can be edited and deleted.
This step becomes available to set up only if Authorization needs to make additional HTTP requests to receive/update an access token. Available for Authorization methods “with login and password” and “with API key”.
Requests widget for receiving and updating tokens are created and set up.
If the token needs to be refreshed exactly through the refreshToken, you need put a check in Use RefreshToken box:
This checkbox allows in the Response tab of the first request widget (which receives the Access token) to save the Refresh token received in the response to a variable:
Further, creating a token update request widget, this variable will be available in the Request tab, and the value of the variable (which we have previously saved) will be passed in the token update request.
The first request widget is added. This HTTP request is made at creating a connection. Specify URL, method and format of the request, as well as set up the body and headers. The key of the variable is indicated in the left field, the value is in the right, where dynamic variables (authorization fields) can be substituted. It is also necessary to set up the Response tab, it indicates the value to take in the Response variable and to save in the accessToken variable. It will be further transmitted for all outgoing HTTP requests from the application.
If you need to update a token, add the same request widget in the “Update token” section. In this request, you can again pass the same dynamic variables, as well as previously received Access token and Refresh token.
It is important to set up the response parser in the Response tab in order to receive, update and save a new access token.
An update request is made at the moment when any app entities makes an outgoing HTTP request and the app (service) give an error that the token has expired (the widget must have Errors handling with the appropriate type)
This step appears for any type and method of Authorization.
A “template” of the behavior of all future HTTP requests to the API is set up. It will be associated with this Authorization. It means all the necessary parameters set at this step will be substituted. It is a “cut” version of the request widget.
You can use both fields and authorization parameters. The list of fields depends on the selected method and type. For example, if the Authorization method is oAuth and With API key_,_ the dynamic API Key (accessToken)variable is available_._ This variable has the value saved using the HTTP request at creating a connection and exchanging data for token access. If the Authorization type is “with login and password”, the dynamic variable Login and password in base64 format will be available, by gluing the login and password through the symbol : in base64 format.
Available fields:
Get parameters: The necessary parameters are entered manually and the values are substituted. Everything indicated in this field will transfer the entered data with each HTTP request, substituting exactly as GET parameters
Headers: fields are created, indicating the key in the left field and substituting the value in the right field
Parameters: create fields that will be transferred in the request body
This is the last step. Saving it, you complete the Authorization. Now you proceed to the settings of the rest entities.
Step 1. Authorization settings
Enter an Authorization name, type and method at this step. Using the oAuth method, set up additional fields.
Type and Method cannot be edited when Authorization is completed. In case of incorrect type or method, create the Authorization again.
Step 2. Authorization fields
This step appears for Custom type only.
Fields required for Authorization are created, which will be requested from the end user at the time of creating app connection.
All created fields will be displayed for filling, the values of these fields will be saved within the connection.
The fields themselves can be used as dynamic variables in the next steps, substituting them in HTTP requests.
Creating a field, fill in the following values:
Field code: internal ID field
Name in English: name will be displayed to the end-user in Albato English interface
Name in Russian: name will be displayed to the end-user in Albato Russian interface
Hint in English: text will be shown under the required field as an explanation. Displayed in Albato English interface.
Hint in Russian: text will be shown under the required field as an explanation. Displayed in Albato Russian interface.
Type: field type is selected. There are: string – a regular input string; integer – allows to store only numbers; email – allows to validate email before saving; password – entered data will be hidden with dots; subdomain - the end-user will see a static prefix and postfix; boolean - checkbox field.
All fields can be edited and deleted.
Step 3. HTTP authorization requests
This step becomes available to set up only if Authorization needs to make additional HTTP requests to receive/update an access token. Available for Authorization methods “with login and password” and “with API key”.
Requests widget for receiving and updating tokens are created and set up.
If the token needs to be refreshed exactly through the refreshToken, you need put a check in Use RefreshToken box:
This checkbox allows in the Response tab of the first request widget (which receives the Access token) to save the Refresh token received in the response to a variable:
Further, creating a token update request widget, this variable will be available in the Request tab, and the value of the variable (which we have previously saved) will be passed in the token update request.
The first request widget is added. This HTTP request is made at creating a connection. Specify URL, method and format of the request, as well as set up the body and headers. The key of the variable is indicated in the left field, the value is in the right, where dynamic variables (authorization fields) can be substituted. It is also necessary to set up the Response tab, it indicates the value to take in the Response variable and to save in the accessToken variable. It will be further transmitted for all outgoing HTTP requests from the application.
If you need to update a token, add the same request widget in the “Update token” section. In this request, you can again pass the same dynamic variables, as well as previously received Access token and Refresh token.
It is important to set up the response parser in the Response tab in order to receive, update and save a new access token.
An update request is made at the moment when any app entities makes an outgoing HTTP request and the app (service) give an error that the token has expired (the widget must have Errors handling with the appropriate type)
Step 4. HTTP request template
This step appears for any type and method of Authorization.
A “template” of the behavior of all future HTTP requests to the API is set up. It will be associated with this Authorization. It means all the necessary parameters set at this step will be substituted. It is a “cut” version of the request widget.
You can use both fields and authorization parameters. The list of fields depends on the selected method and type. For example, if the Authorization method is oAuth and With API key_,_ the dynamic API Key (accessToken)variable is available_._ This variable has the value saved using the HTTP request at creating a connection and exchanging data for token access. If the Authorization type is “with login and password”, the dynamic variable Login and password in base64 format will be available, by gluing the login and password through the symbol : in base64 format.
Available fields:
Get parameters: The necessary parameters are entered manually and the values are substituted. Everything indicated in this field will transfer the entered data with each HTTP request, substituting exactly as GET parameters
Headers: fields are created, indicating the key in the left field and substituting the value in the right field
Parameters: create fields that will be transferred in the request body
This is the last step. Saving it, you complete the Authorization. Now you proceed to the settings of the rest entities.
Updated on: 07/12/2022
Thank you!