fixes #178 add pre-commit hook and apply it (#179)

.pre-commit-config.yaml

@@ -0,0 +1,14 @@
+repos:
+-   repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v3.2.0
+    hooks:
+    -   id: trailing-whitespace
+    -   id: end-of-file-fixer
+    -   id: check-yaml
+    -   id: check-added-large-files
+-   repo: https://github.com/networknt/pre-commit-hook-keyword
+    rev: f17c4de14fc24420f6768c19cad06ba03af06d86
+    hooks:
+    -   id: keywordscan
+        args: ["--keywords=c3VubGlmZQ==,Y2liYw==,c3VuIGxpZmU="]
+        types: ["text"]

NOTICE

@@ -67,4 +67,3 @@ distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
-

README.md

@@ -1,55 +1,55 @@
-## light-gateway:   
+## light-gateway:
 
-A standalone gateway combined light-proxy and light-router to address cross-cutting concerns for incoming and outgoing requests. Compared with the [http-sidecar](https://github.com/networknt/http-sidecar), which has the same light-proxy and light-router features, the light-gateway is more flexible for deployment. It can be deployed in a container, a Windows service or a Linux service. There might be multiple clients and services for light-gateway to support many-to-many communication. However, the http-sidecar is designed to deploy in the same Kubernetes pod with the backend API to form a one-to-one relationship. In other words, the http-sidecar is a stripped-down version of the light-gateway. 
+A standalone gateway combined light-proxy and light-router to address cross-cutting concerns for incoming and outgoing requests. Compared with the [http-sidecar](https://github.com/networknt/http-sidecar), which has the same light-proxy and light-router features, the light-gateway is more flexible for deployment. It can be deployed in a container, a Windows service or a Linux service. There might be multiple clients and services for light-gateway to support many-to-many communication. However, the http-sidecar is designed to deploy in the same Kubernetes pod with the backend API to form a one-to-one relationship. In other words, the http-sidecar is a stripped-down version of the light-gateway.
 
 ### Deployment Pattern
 
-There are 6 patterns to deploy the light-gateway and the only difference is the configuration. The same jar file or docker image can be used for different use cases. 
+There are 6 patterns to deploy the light-gateway and the only difference is the configuration. The same jar file or docker image can be used for different use cases.
 
 * External Gateway
 
-The external gateway is deployed in the DMZ to help the third-party clients access APIs in the DMZ or corporate network. It is a shared gateway for multiple clients to access a limited number of APIs inside. Compared with the internal gateway, it has more security handlers configured. For example, an IP whitelist handler will allow certain IP addresses to access the gateway, or a rate-limiting handler is set up to prevent DDoS attacks, etc. 
+The external gateway is deployed in the DMZ to help the third-party clients access APIs in the DMZ or corporate network. It is a shared gateway for multiple clients to access a limited number of APIs inside. Compared with the internal gateway, it has more security handlers configured. For example, an IP whitelist handler will allow certain IP addresses to access the gateway, or a rate-limiting handler is set up to prevent DDoS attacks, etc.
 
-Verifying the JWT tokens is a very common practice on the external gateway to ensure only the valid requests will be passed through the firewall and sent to the internal gateway. 
+Verifying the JWT tokens is a very common practice on the external gateway to ensure only the valid requests will be passed through the firewall and sent to the internal gateway.
 
 * Internal Gateway
 
-The internal gateway is another shared gateway deployed inside the corporate network to help legacy clients to communicate with legacy services. The configuration should be very similar to the external gateway but remove some middleware handlers. For example, JWT token signature verification might not be enabled on the internal gateway. 
+The internal gateway is another shared gateway deployed inside the corporate network to help legacy clients to communicate with legacy services. The configuration should be very similar to the external gateway but remove some middleware handlers. For example, JWT token signature verification might not be enabled on the internal gateway.
 
 * Client Router
 
-In this pattern, only the router feature of the light-gateway is used to bring the legacy client to the light ecosystem. The instance is dedicated to a particular client application like a monolithic web server and deployed on the same host. 
+In this pattern, only the router feature of the light-gateway is used to bring the legacy client to the light ecosystem. The instance is dedicated to a particular client application like a monolithic web server and deployed on the same host.
 
-The gateway is responsible for getting the JWT token on behalf of the client, caching it, and renewing it before expiration. Also, the gateway will route all the API accesses so that the client will only deal with one API regardless of how many are behind the gateway. 
+The gateway is responsible for getting the JWT token on behalf of the client, caching it, and renewing it before expiration. Also, the gateway will route all the API accesses so that the client will only deal with one API regardless of how many are behind the gateway.
 
 * Service Proxy
 
-In this pattern, only the reverse proxy feature of the light-gateway is used to bring the legacy service to the light ecosystem. The instance is dedicated to a particular service that exposes some API endpoints. 
+In this pattern, only the reverse proxy feature of the light-gateway is used to bring the legacy service to the light ecosystem. The instance is dedicated to a particular service that exposes some API endpoints.
 
-The gateway is responsible for verifying the JWT token, validating the incoming requests, and all other cross-cutting concerns. Then the request will be forwarded to one or many backend instances. With the light-gateway deployed on the same server, you don't need to update anything on the legacy server. 
+The gateway is responsible for verifying the JWT token, validating the incoming requests, and all other cross-cutting concerns. Then the request will be forwarded to one or many backend instances. With the light-gateway deployed on the same server, you don't need to update anything on the legacy server.
 
 
 * Service Gateway
 
-This pattern is similar to the service proxy but has the router feature enabled simultaneously. It is for legacy a service that accepts incoming requests and calls other APIs. 
+This pattern is similar to the service proxy but has the router feature enabled simultaneously. It is for legacy a service that accepts incoming requests and calls other APIs.
 
 
 * Backend as Frontend
 
-This is for a big application that will access a lot of backend microservices. The light-gateway will aggregate all the backend API together so that the client application can deal with only one API instead of hundreds. For example, a mobile banking application needs to access a lot of microservices for its functionalities. 
+This is for a big application that will access a lot of backend microservices. The light-gateway will aggregate all the backend API together so that the client application can deal with only one API instead of hundreds. For example, a mobile banking application needs to access a lot of microservices for its functionalities.
 
 * SPA Server
 
-This is a similar pattern like the Backend as Frontend with added feature to serve the single page application on the same server without cors enabled. 
+This is a similar pattern like the Backend as Frontend with added feature to serve the single page application on the same server without cors enabled.
+
 
 
-
     light-gateway can be deployed as API gateway to handle restful request/response related functionalities which include:
-     
+
      - Package and deployed as separate module to handle Cross-Cutting Concerns for main container/service in the same pod. In this case, the main service only need care about the http request/response and business logic
-     
+
      - Ingress traffic: client  request(legacy) will come to light-gateway first, light-gateway act as a proxy to delegate light client features, which include, openapi schema validation, observability, monitoring, logging, JWT verify, etc. Then forward the request to main service.
-      
+
      - Egress traffic: main service call through light-gateway for egress traffic; in this case, light-gateway act as a router to delegate light client features, which include service discovery, SSL handshake, JWT token management, etc. Then forward the request to server API.
 
 
@@ -67,41 +67,41 @@ By default, the light-gateway works as internet gateway for both proxy/router fe
 
 Please refer to default setting for detail:
 
- [handler](https://github.com/networknt/light-gateway/blob/master/src/main/resources/config/handler.yml)  
- [values](https://github.com/networknt/light-gateway/blob/master/src/main/resources/config/values.yml)  
+ [handler](https://github.com/networknt/light-gateway/blob/master/src/main/resources/config/handler.yml)
+ [values](https://github.com/networknt/light-gateway/blob/master/src/main/resources/config/values.yml)
 
 ### Light-gateway features and config setting:
 
-- Proxy 
+- Proxy
 
   Light-gateway Proxy used for dispatch the request from light-4j API to existing system (legacy). Since existing system may not have some microservice features, for example:
-  
+
   - Audit log
   - JWT verify
-  - Metrics  
+  - Metrics
   - Openapi schema validation
-  
+
   Light-gateway proxy can handle those features and forward the request to  existing system.
-      
+
   The major config for proxy is "proxy.host", user can define a list of proxy destination host separate by ",'. For example
-  
+
   proxy.host: https://localhost:9443,http://localhost:8080,https://www.networknt.com
 
 - Router
 
   Light-gateway Router used for dispatch the request from existing system to light-4j restful API. Normally the existing system doesn't support some microservice feature for service call:
-   
-  - Service discovery 
+
+  - Service discovery
   - Audit log
   - JWT populate
   - Metrics
 
   Light-gateway Router can handle those features and forward the request to new microservice API.
-  
+
   Light-gateway Router be triggered if the request header include key "service_id" or "service_url" (if both existing, service_url will be taken first)
 
   The major config for the router includes:
-  
+
   serviceDict.mapping:
   router.hostWhitelist:
 
@@ -110,7 +110,7 @@ Please refer to default setting for detail:
 
 If you want to use SidecarServiceDictHandler to get the service Id by the path url mapping from serviceDict.yml, add it before token handlers and router handler. The service Id get from serviceDict
 will be used for next handler chain.
-  
+
 ```
   - com.networknt.router.middleware.GatewayServiceDictHandler@path
   - com.networknt.router.middleware.GatewaySAMLTokenHandler@saml
@@ -139,15 +139,15 @@ java -jar -Dlight-4j-config-dir=config/local  target/light-gateway.jar
 
 ```
 
-The light-gateway service will start on http port 9080 and https port 9445. 
+The light-gateway service will start on http port 9080 and https port 9445.
 
 The service API could use any technologies, like NodeJs, .nets, php service...; The light-gateway service will handle the ingress and egress traffic to the pod and leverage light-4j cross-cutting concerns and client module features.
 
 
 
-- Start Nodejs restful API (It is simulate the service in the Pod) 
+- Start Nodejs restful API (It is simulate the service in the Pod)
 
-Follow the [steps](nodeapp/start.md) to start Nodejs books store restful API. The Nodejs api will start on local port: 8080 
+Follow the [steps](nodeapp/start.md) to start Nodejs books store restful API. The Nodejs api will start on local port: 8080
 
 We can verify the Nodejs restful API directly with curl command:
 
@@ -193,7 +193,7 @@ java -jar target/petstore-service-api-3.0.1.jar
 
 ```
 
-The petstore light-api will start on local https 8443 port. 
+The petstore light-api will start on local https 8443 port.
 
 
 - Try the call by using light-gateway:
@@ -243,13 +243,11 @@ Graalvm and its native-image are required to compile uber jar file native execut
 
 ```
   mvn clean install
-  
+
   native-image -jar target/light-gateway.jar -o target/application
 ```
 you can execute the generated executable with following command:
 
 ```
   target/application -Dight-4j-config-dir=config/local
 ```
-
-

config/client-gateway/logback.xml

@@ -103,4 +103,4 @@
         <appender-ref ref="stdout"/>
     </logger>
 
-</configuration>
+</configuration>

config/client-proxy-market/logback.xml

@@ -103,4 +103,4 @@
         <appender-ref ref="stdout"/>
     </logger>
 
-</configuration>
+</configuration>

config/client-proxy-transform/logback.xml

@@ -107,4 +107,4 @@
         <appender-ref ref="stdout"/>
     </logger>
 
-</configuration>
+</configuration>

config/light-portal/logback.xml

@@ -103,4 +103,4 @@
         <appender-ref ref="stdout"/>
     </logger>
 
-</configuration>
+</configuration>

config/light-portal/values.yml

@@ -163,4 +163,3 @@ cors.allowedMethods:
 #openapi-security.yml
 openapi-security.skipPathPrefixes:
   /adm
-

config/light-portal/virtual-host.yml

@@ -11,4 +11,3 @@ hosts:
     base: /signin/build
     transferMinSize: 10245760
     directoryListingEnabled: false
-

config/metrics-test/README.md

@@ -1,4 +1,3 @@
 This is a test folder for metrics tests to ensure that router handler will have an entry as part of the metrics payload.
 
-In this configuration, we are using the petstore for the downstream API with router handler enabled in the chain. 
-
+In this configuration, we are using the petstore for the downstream API with router handler enabled in the chain.

config/metrics-test/logback.xml

@@ -106,4 +106,4 @@
         <appender-ref ref="stdout"/>
     </logger>
 
-</configuration>
+</configuration>

config/server-gateway/README.md

@@ -1,2 +1 @@
 1. Chaos-Monkey is enabled in shared gateway and server-gateway. client gateway doesn't need Chaos Monkey.
-

config/server-gateway/logback.xml

@@ -103,4 +103,4 @@
         <appender-ref ref="stdout"/>
     </logger>
 
-</configuration>
+</configuration>

config/server-proxy-petstore/README.md

@@ -1,3 +1 @@
 This is the configuration to demonstrate the light-gateway acts as a server proxy to bring a legacy service to the light ecosystem. For more info, please refer to the [tutorial]()
-
-

config/server-proxy-petstore/logback.xml

@@ -103,4 +103,4 @@
         <appender-ref ref="stdout"/>
     </logger>
 
-</configuration>
+</configuration>

config/shared-gateway/README.md

@@ -1 +1 @@
-This folder contains a list of example config files to set up the light-router as a shared gateway.  Please refer to the [shared-gateway tutorial](https://doc.networknt.com/tutorial/rotuer/shared-gateway/) for more information.
+This folder contains a list of example config files to set up the light-router as a shared gateway.  Please refer to the [shared-gateway tutorial](https://doc.networknt.com/tutorial/rotuer/shared-gateway/) for more information.

config/shared-gateway/logback.xml

@@ -103,4 +103,4 @@
         <appender-ref ref="stdout"/>
     </logger>
 
-</configuration>
+</configuration>

k8s/overlays/dev/config/values.yml

@@ -1,4 +1,4 @@
 # customize other configuration files packaged in the container with the following properties.
 
 # The server environment tag
-server.environment: dev-mesh
+server.environment: dev-mesh

k8s/overlays/prd/config/values.yml

@@ -1,4 +1,4 @@
 # customize other configuration files packaged in the container with the following properties.
 
 # The server environment tag
-server.environment: prd-mesh
+server.environment: prd-mesh

k8s/overlays/sit/config/values.yml

@@ -1,4 +1,4 @@
 # customize other configuration files packaged in the container with the following properties.
 
 # The server environment tag
-server.environment: sit-mesh
+server.environment: sit-mesh

k8s/overlays/stg/config/values.yml

@@ -1,4 +1,4 @@
 # customize other configuration files packaged in the container with the following properties.
 
 # The server environment tag
-server.environment: stg-mesh
+server.environment: stg-mesh

nodeapp/server.js

@@ -59,4 +59,4 @@ res.send(book);
 
 //PORT ENVIRONMENT VARIABLE
 const port = process.env.PORT || 8080;
-app.listen(port, () => console.log(`Listening on port ${port}..`));
+app.listen(port, () => console.log(`Listening on port ${port}..`));

nodeapp/start.md

@@ -59,4 +59,3 @@ Method: GET
 request body:
 {"name":"mybook"}
 ```
-

product/external-access-point/README.md

@@ -1,6 +1,6 @@
-This is an example configuration for [external access point](https://doc.networknt.com/service/gateway/external-access-point/) usage of light-gateway. Basically it is a micro-gateway for third-party consumers to access internal or external APIs controlled by an organization. 
+This is an example configuration for [external access point](https://doc.networknt.com/service/gateway/external-access-point/) usage of light-gateway. Basically it is a micro-gateway for third-party consumers to access internal or external APIs controlled by an organization.
 
-In this example, we are going to expose two externall APIs with updated paths with URL rewriting. We aslo set up an Okta instance to protect the API with client credentials token. The two API endpoints are public without any protection. 
+In this example, we are going to expose two externall APIs with updated paths with URL rewriting. We aslo set up an Okta instance to protect the API with client credentials token. The two API endpoints are public without any protection.
 
 Here is the detail about the three APIs:
 
@@ -17,14 +17,13 @@ https://catfact.ninja/fact
 https://dummy.restapiexample.com/api/v1/employees
 
 
-We are going to rewrite the url for the above APIs to /v1/cats and /v1/employees. The /v1/pets is the same as the downstream API so there is no need to rewrite the URL. 
+We are going to rewrite the url for the above APIs to /v1/cats and /v1/employees. The /v1/pets is the same as the downstream API so there is no need to rewrite the URL.
 
-If your organization needs an http gateway to access external API, you have to use the external service with proxy config and also the client module will need to set up the proxy. 
+If your organization needs an http gateway to access external API, you have to use the external service with proxy config and also the client module will need to set up the proxy.
 
-You can also create an openapi.yaml specification file that include all the endpoints for validation and scope validation for security. 
+You can also create an openapi.yaml specification file that include all the endpoints for validation and scope validation for security.
 
 
-Here is a tutorial that walk through the example. 
+Here is a tutorial that walk through the example.
 
 [External Access Point](https://youtu.be/h0fGpd-u6D0)
-

product/external-access-point/logback.xml

@@ -103,4 +103,4 @@
         <appender-ref ref="stdout"/>
     </logger>
 
-</configuration>
+</configuration>

product/external-access-point/values.yml

@@ -49,7 +49,7 @@ handler.handlers:
   - com.networknt.router.OAuthServerHandler@oauth
   - com.networknt.router.OAuthServerGetHandler@getOauth
   - com.networknt.server.handler.ServerShutdownHandler@shutdown
-  
+
 handler.chains.default:
   # - whitelist
   - exception
@@ -104,7 +104,7 @@ openapi-security.enableVerifyJwt: true
 openapi-security.enableExtractScopeToken: false
 # Enable JWT scope verification. Only valid when enableVerifyJwt is true.
 openapi-security.enableVerifyScope: false
-# Enable JWT scope verification. 
+# Enable JWT scope verification.
 # Only valid when (enableVerifyJwt is true) AND (enableVerifyScope is true)
 openapi-security.enableVerifyJwtScopeToken: false
 openapi-security.keyResolver: JsonWebKeySet
@@ -169,12 +169,12 @@ externalService.enabled: false
 externalService.proxyHost: proxy-mwg-http.networknt.com
 externalService.proxyPort: 8443
 externalService.enableHttp2: false
-externalService.pathHostMappings: 
+externalService.pathHostMappings:
   # BlackRock
   - /v1/cats https://catfact.ninja
   - /v1/employees https://dummy.restapiexample.com
-  
-externalService.urlRewriteRules:  
+
+externalService.urlRewriteRules:
   - /v1/cats /fact
   - /v1/employees /api/v1/employees