This repository was archived by the owner on May 28, 2021. It is now read-only.
Flow
Each VRT will get a unique access token and identifier which will be used for obtaining Widgets.
Currently there are 2 types of VRTs:
- Badge
- Terminal
- The User will authenticate itself using the Password Grant Flow (OAuth2) and receive an access token for further communication.
- The access token will be used for obtaining the membership information. Each membership information may have multiple VRTs associated with it.
- Each VRT will obtain its widgets using its identifier and the access token. (Access Token used by VRT may be different from the user's access token, and is an implementation detail which might change)
- The VRT will get the access token and unique identifier directly. (Maybe with these embedded in QR for now).
Each Widget will have 3 components associated with it:
- Form/Schema - The elements/components to be rendered ( maybe along with certain actions, which will access a process).
- Template/Styles - The layout & styling to be applied to each component.
- Authorization - Each widget will be adding a special header/ url parameter for A&A while invoking a
process.
- First Market-Place will register at kong with upstream_url let say
m.veris.in - Admin registers his micro-services at Market Place (he will give us the upstream_url - uber.veris.in and various request paths) , parrllely we will register the same service at kong with same upstream_url - uber.veris.in
- Admin wants to make a process P1 , so he said list me all micro-service that I can use , we list him APIs from Resource micro-service
- using them he makes a process P1 (p1 have , upstream_url -> k.veris.in , HOST - uber.veris.in)
- so P1 will use url
- http://k.veris.in/rides/
- Header - HOST uber.veris.in
- So here kong will act as a proxy server and using HOST header & request-path from url , he will proxy to uber.veris.in/rides
* Currently we will introduce statically coded widgets on the client side (as we did in the V3 teaser)