In the previous remote service tutorial, we have demonstrated how to leverage remote test cloud services from the local Nodejs server for UI developers. The tutorial is only suitable for pure UI developers who only know the API of the backend services and focus 100% on the React UI application. In most organizations, there might be some full-stack developers who have to work on both SPA and backend APIs at the same time. Read More »

Until now, we are using the local Consul server, local light-oauth2 services, and local open-banking services for the react-client development. If I am a developer who is working on both front end and backend, this is OK as both might be changing at the same time. By deploying everything on the local desktop with Docker, we can easily make a change and redeploy the backend services. But what if I am just a front-end React developer? Read More »

In the oauth config tutorial, we have created a client for the react-client application. One has the redirect URI https://ob.lightapi.net for production, and another has the redirect URI https://localhost:3000 for local development. There are two client_ids available, and we have to put the client_id into the react-client application login function to access the /oauth/code endpoint. Here is the login function in ResponsiveDrawer.js const login = () => { window.location = "https://obsignin. Read More »

In the previous steps, we are using virtual host ob.lightapi.net to test the react-client for the Open Banking services. For a simple React application development, it is OK; however, if there are too many components that need to be modified and tested. By building the react application into the build folder, copy to the light-rest-config folder and restart the light-router instance, it is not efficient. For the developer’s productivity, we need to find a way to start the React application with the builtin Nodejs server and proxy the API calls to the light-router instance running locally. Read More »

Before we start the react-client, let’s introduce the local and test cloud environments first. Local We are trying our best to mimic the local environment like the test cloud so that we can deploy all components to the test cloud without a lot of changes in configuration. For the initial development of the react-client, we are going to use the Nodejs server to leverage the hot reload. Even when we hook up with the light-oauth2 for the authentication and authorization, we can still use the localhost:3000; however, as OAuth 2. Read More »

The light-router instance serves the Single Page Application and acts as a proxy and load balancer to access the APIs behind it. From the previous login-view, we have seen the complicated interactions between the Single Page Application, Login View of OAuth 2.0 provider, and the StatelessAuthHandler wired in the light-router chain. This puts the light-router as a central point in the entire application. To solve issues with the UI, and microservices, it is easier to debug into the router instance. Read More »

Before we hook up the light-oauth2 to complete the Authorization Code grant flow, we need to create two clients and two users in the database configuration. As we want to register the light-oauth2 services to the Consul for the light-router to look up, we need to make a separate configuration in the light-config-test repository. docker-compose We use a docker-compose.yml to start the services. If you look at the above docker-compose.yml file, you will realize the following. Read More »

In the previous steps, we are using long-lived tokens to access services. With a single page application, we can also close the entire loop of the OAuth 2.0 authorization code flow. To start a React application, we need to create a repo on GitHub under the open-banking organization. Then clone the repo to the open-banking folder under the home directory. git clone [email protected]:open-banking/react-client.git npx create-react-app react-client yarn start A browser tab will be started automatically after the node server is up with the SPA. Read More »

In the previous step, we started the light-oauth2 services locally. In this section, we are going to start the light-router instance to act as a consumer proxy and host the two single-page applications as a virtual host. After we completed the cookie code and tested it, we need to deploy the react application build to the local-openbanking folder to host it by the light-router. For each secured client application, we need to have a light-router instance to handle Internet access, so we cannot reuse the light-portal instance for the portal server anymore. Read More »

In previous steps, we have tested the demo application on the local. Now, it is time to deploy the application to the test cloud. The two built sites are in the following folder in the light-config-test repository. https://github.com/networknt/light-config-test/tree/master/light-router/test-openbanking The light-router docker-compose file looks like the following. version: '2' services: light-router: image: networknt/light-router:latest # networks: # - localnet ports: - 8443:8443 volumes: - ./config:/config - ./obsignin/build:/obsignin/build - ./ob/build:/ob/build network_mode: host The configuration for the light-router is located at Read More »

In the previous step, we have walked through the react-client app with hard-coded long-lived token without hooking up with the light-oauth2 services. Before we enable the default chain in the router handler.yml file to add the StatelessAuthHandler to the chain, we are using the hard-coded OAuth 2.0 access token in the useApiGet hook. We can use the react yarn start and test from the localhost:3000 with the hot reload without logging in. Read More »