Hello, team Wallarm. I have studied your documentation, i have a question. Tell me if it is possible to change the http response code in the blocking mode through variables. By default, as I understand it, it is 403. But sometimes it is more convenient to be able to set your own response code, for accurate diagnostics by logs, or for introducing a custom page when blocking the api by a firewall.

This application is a really nice tool and I can imagine numerous applications for this model. What I would like to suggest is an additional module that would allow for zero trust via x509 key pair. This would allow users to deploy unconfigured versions on their applications and the said application could just auth with a key pair, request what it needs to request for an initial configuration download.

Private key verification could be integrated into cloud-based key storage like Google KMS, an intermediate CA, or even stored locally on the host machine's file system or k8s secrets.

Is there a configuration parameter to bypass the certificate validity checking for upstream / proxied APIs?

This is the error I am getting {"level":"error","msg":"#0000000100000001 : error while proxying request: x509: certificate is valid for abc.xyz.net not abc","time":"2021-11-17T10:44:07Z"}

This would be helpful for self signed certificates and networks that are not directly internet accessible.

Hi, in OpenAPI 2 there was a top-level property called basePath which (if set) defined the base path before all API endpoints, like /api/v1. In OpenAPI 3 this was removed, but the Swagger OpenAPI 3.0 docs and the spec itself suggest putting the base path in the server URL like this:

servers:
- url: "https://api.my-service.com/api/v1"
- url: "https://staging-api.my-service.com/api/v1"

Without support for a base path, all of my API endpoints are rejected because they are missing the /api/v1 portion (my base path).

Four ways to solve this problem come to mind:

1. Change all my endpoint paths to include the base path (this doesn't seem ideal since the docs suggest I use a base path in the server URL).
2. Run my OpenAPI spec through a preprocessor that prepends the base path to each endpoint before you read it.
3. You can infer the base path from the servers by capturing the path of the first server URL (if present). This is what the AWS API Gateway does.
4. You can provide an environment variable / CLI argument to set the base path like APIFW_API_BASE_PATH.

I would be happy to contribute this enhancement but I don't see the source code anywhere. Also, you might want to clarify the license of this product.

File upload api is being blocked when it should be allowed. Can you please suggest what can be changed in order to allow this upload? The spec has it defined as { "/document/upload": { "post": { "tags": [ "document-controller" ], "operationId": "Document_1", "parameters": [ { "name": "id", "in": "query", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "multipart/form-data": { "schema": { "required": [ "file" ], "type": "object", "properties": { "file": { "type": "string", "format": "binary" } } } } } }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "type": "string" } } } } } } } }

The error when uploading a docx is api-firewall | time=2021-12-04T17:32:18Z level=error msg=#0000000900000001 : request validation error: request body has an error: failed to decode request body: path file: unsupported content type "application/vnd.openxmlformats-officedocument.wordprocessingml.document"

The content type passed in request header is Content-Type multipart/form-data; boundary=---------------------------162567064334244515552744535554 Request itself is `-----------------------------162567064334244515552744535554 Content-Disposition: form-data; name="file"; filename="mydoc.docx" Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document

TEST-doc

-----------------------------162567064334244515552744535554-- `

Ideally, when I design an endpoint, I should be able to say how each method is authorized. In OAuth, we use scopes to determine the extent of access granted for an access_token ("AT"). The AT may be a value token: a JWT requiring signature validation (and auto-fetching of the current keys). The AT may also be a reference token: a guess-resistent identifier requiring OAuth token introspection. In either case, the AT should contain the scope claim, which is a space-delimited list of scopes (normally in URI format).

In the example below, the swagger doc is saying that to do a GET on the persistence endpoint, you need to present a token with either the properties.read OR properties.write scope

/jans-config-api/api/v1/jans-auth-server/config/persistence:
    get:
      summary: Returns persistence type configured for Jans authorization server.
      description: Returns persistence type configured for Jans authorization server.
      operationId: get-properties-persistence
      security:
        - oauth2: [properties.read, properties.write]

For extra credit, you can consider how the scopes are combined. Can you use AND instead of OR for a given endpoint? For more complex booleans, you could support JSONLogic syntax.

When configuring request body schema with an integer type field and sending a valid request, it produces a validation error with the value considered as null.

Minimal example built by adjusting the docker-compose demo in this repo: int-example.json instead of httpbin.json:

{
  "openapi": "3.0.1",
  "info": {
    "title": "Minimal integer field example",
    "version": "0.0.1"
  },
  "paths": {
    "/integer-field": {
      "post": {
        "requestBody": {
          "content": {
            "application/json": {
              "schema": {
                "type": "object",
                "properties": {
                  "count": {
                    "type": "integer"
                  }
                }
              }
            }
          }
        },
        "responses": {
          "200": {
            "description": "Success"
          }
        }
      }
    }
  }
}

Add these env vars to the original docker-compose demo:

APIFW_API_SPECS: "/opt/resources/int-example.json"
APIFW_LOG_LEVEL: "DEBUG"
APIFW_ADD_VALIDATION_STATUS_HEADER: "true"

Request (curl):

curl -X POST http://localhost:8080/integer-field \
   -H 'Content-Type: application/json' \
   -d '{"count":1}'

Error in log:

time=2022-12-12T11:51:11Z level=error msg=request validation error error=request body has an error: doesn't match the schema: Error at "/count": Value is not nullable
Schema:
  {
    "type": "integer"
  }

Value:
  null
 request_id=#0000000400000001

Hi! Building https://github.com/wallarm/api-firewall-docker/blob/5cd07f115f16d10095a385a73568a4e60caf278b/0.6.7/Dockerfile on i386 (docker build --platform linux/386) fails with /bin/sh: api-firewall: not found.

When downloading https://github.com/wallarm/api-firewall/releases/download/v0.6.7/api-firewall-386-musl.tar.gz in an amd64 container instead, I can successfully ldd (and run!) the binary:

$ docker run -it --rm alpine:3.15
/ # wget https://github.com/wallarm/api-firewall/releases/download/v0.6.7/api-firewall-386-musl.tar.gz
Connecting to github.com (192.30.255.113:443)
Connecting to objects.githubusercontent.com (185.199.111.133:443)
saving to 'api-firewall-386-musl.tar.gz'
api-firewall-386-mus 100% |********************************| 3589k  0:00:00 ETA
'api-firewall-386-musl.tar.gz' saved
/ # tar -xvf api-firewall-386-musl.tar.gz
./
./api-firewall
./LICENSE
/ # ldd api-firewall
	/lib/ld-musl-x86_64.so.1 (0x7f2461ac7000)
	libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f2461ac7000)
/ # ./api-firewall -v
Version: 0.6.7
Wallarm API-Firewall

I'm not 100% certain I'm looking in the right place, but it seems like https://github.com/wallarm/api-firewall/blob/9a2d7f2bd3c9c68360c54e01cb3c749a6ee11e7b/.github/workflows/binaries.yml#L156 is maybe missing the same case block to set GOARCH=386 as build-x86: has? https://github.com/wallarm/api-firewall/blob/9a2d7f2bd3c9c68360c54e01cb3c749a6ee11e7b/.github/workflows/binaries.yml#L95-L102

Honestly, it should be pretty safe to just set GOARCH unilaterally -- if you're on amd64 and explicitly set GOARCH=amd64, it doesn't do anything (since that's the default detected value for that case). :sweat_smile:

(Also, setting GOHOSTARCH and GOHOSTOS explicitly like that shouldn't be necessary.)

Does fasthttp accidentally keep connected connections, if so, it would be more appropriate to use this configuration:

worker_processes 8; # equal to number of CPU cores on our machine
...
upstream backend {
    server 127.0.0.1:9090;
    keepalive 8;
}
...
client_body_buffer_size 128K; # greater than our JSON file size
... 
       location / {
                proxy_pass http://backend;
                proxy_http_version 1.1;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Connection "";
        }

Updates:

• Add support of the OpenAPI spec loading via URL. From now on it's possible to set openapi specification URL to env var APIFW_API_SPECS.
• Add custom Content-Type of the request to introspection endpoint. Custom content-type could be set to the env var APIFW_SERVER_OAUTH_INTROSPECTION_CONTENT_TYPE.

response sequence for log

                    logger.Infof("(%d) : #%016X : %s %s -> %s (%s)",
                            ctx.Response.StatusCode(),
                            ctx.ID(),
                            ctx.Request.Header.Method(), ctx.Path(),
                            ctx.RemoteAddr(), time.Since(start),
                    )