After checking the login parameters for the user and password, you need to send a response.
No registered user: It's up to you to decide what you want to send. You can put an error in the response, so BOA will display the login screen again to the user.
{
"error": "nok",
"token": ""
}
Succesfull login
If the login is succesfull the response needs to contain some elements, so BOA can start with building the application you want. There are some main elements in the response you must provide:
Configuration data specific for the user, the appname, the language to use, radius of the button corners and a token.
Menu data to build the menu on the left side of the application. This is a multi-level menu that you define.
Topmenu data for the top menu, this is also a multi-level menu.
After processing this data, the application with the main options appears. This has the following look.
BOA application with left and top menu.
Configuration elements
The configuration has the following elements:
{ "login": "ok",
"token": "eyJhbGI...0Ttctbk",
"language": "EN",
"appname": "Demo",
"buttoncorner": 5,
"infopages":"http://...",
"company": [
{ "dossier": "000",
"naam": "Firmanaam BVBA "
}
],
"menu": [...],
"topmenu" : [...] }
login: ok when the login is successfull.
token: an unique token is needed in the response. BOA will send this token with each request to your server.
language: language you want to use. This will be used for standard messages of BOA.
appname: will be displayed in the upper left corner of the application.
buttoncorner: defines the radius of the buttons. Value is from 1 to 99.
1: straight corners
99: rounded corners
infopages: url to help or info pages for the user. BOA displays a '?' sign, to open this url.
company: an array with the possible companies. If the array has more than one element, a popup to choose will appear. This depends on your iAPI.
menu: contains the definition of the left menu.
topmenu: contains the definition of the top menu.
See Menu definition for the info about the setup for the menu's.
Purpose of the token: After login the token will be send with each request for the authorization. It is send as a Bearer authorization. This way your iAPI can check if the request is being send by an authorized user. If you want, you can use a JWT (Json Web Token) which is quite common to use. In the JWT you can put an expiry time for the token. This way a token can expire after some time. If someone has captured it, it will become inactive after the time it contains.
Of course, you are free to build a token as you like, in the format you want. It will be send with each request, and it is up to your iAPI to evaluate it, and to grant access or not. If a token is not valid, you can send an error in your response as follows:
