Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding firewall rule fails with version v1.43.0 #725

Closed
Dari4sho opened this issue Apr 4, 2024 · 3 comments
Closed

Adding firewall rule fails with version v1.43.0 #725

Dari4sho opened this issue Apr 4, 2024 · 3 comments
Labels

Comments

@Dari4sho
Copy link

Dari4sho commented Apr 4, 2024

TL;DR

Starting from v1.43.0, adding a firewall rule fails with hcloud: invalid input in field 'rules' (invalid_input)

Expected behavior

Firewall rule being added successfully

Observed behavior

Adding firewall rule fails with hcloud: invalid input in field 'rules' (invalid_input)

Minimal working example

I am running hcloud on a scheduled pipeline always using the latest version.
Since the release of v1.43.0 yesterday, adding a firewall rule fails for me.

This is the command that I run:
hcloud firewall add-rule 1234567 --direction=in --port=2205 --protocol=tcp --source-ips=12.34.56.78/32 --description="Temp access"

It works fine with version v1.42.0.

Log output

`hcloud: invalid input in field 'rules' (invalid_input)`

Additional information

Fails on version v1.43.0
Works on version v1.42.0

@Dari4sho Dari4sho added the bug label Apr 4, 2024
@apricote
Copy link
Member

apricote commented Apr 5, 2024

Can reproduce, request and response bodies:

--- Request:
POST /v1/firewalls/1254648/actions/set_rules HTTP/1.1
Host: api.hetzner.cloud
User-Agent: hcloud-cli/1.43.0-dev hcloud-go/2.7.0
Content-Length: 499
Authorization: REDACTED
Content-Type: application/json
Accept-Encoding: gzip

{"rules":[{"direction":"in","source_ips":["0.0.0.0/0"],"destination_ips":[],"protocol":"tcp","port":"22","description":null},{"direction":"out","source_ips":[],"destination_ips":["::/0"],"protocol":"tcp","port":"443","description":null},{"direction":"in","source_ips":["2001:db8:123:4567::/64"],"destination_ips":[],"protocol":"tcp","port":"22","description":null},{"direction":"in","source_ips":["12.34.56.78/32"],"destination_ips":null,"protocol":"tcp","port":"2205","description":"Temp access"}]}

--- Response:
HTTP/2.0 422 Unprocessable Entity
Content-Length: 286
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, PATCH, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 1728000
Content-Type: application/json
Date: Fri, 05 Apr 2024 15:30:39 GMT
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Correlation-Id: 34395fd8f78fd233

{
  "error": {
    "message": "invalid input in field 'rules'",
    "code": "invalid_input",
    "details": {
      "fields": [
        {
          "name": "rules.3.destination_ips",
          "messages": [
            "Field may not be null."
          ]
        }
      ]
    }
  }
}

@phm07
Copy link
Contributor

phm07 commented Apr 17, 2024

This was introduced with hetznercloud/hcloud-go#396 and is an unexpected inconsistency with the API. The API does not emit the destination_ips field in responses, but expects it to be omitted in requests. (Same probably goes for description)

phm07 added a commit to hetznercloud/hcloud-go that referenced this issue Apr 17, 2024
Because the Firewall API expects a different JSON formatting than it responds with (some fields must be omitted even though they are included in the response) we have to create an intermediate struct to marshal rules properly.

See hetznercloud/cli#725
phm07 added a commit to hetznercloud/hcloud-go that referenced this issue Apr 18, 2024
Because the Firewall API expects a different JSON formatting than it
responds with (some fields must be omitted even though they are included
in the response) we have to create an intermediate struct to marshal
rules properly.

See hetznercloud/cli#725
github-actions bot pushed a commit to hetznercloud/hcloud-go that referenced this issue Apr 18, 2024
Because the Firewall API expects a different JSON formatting than it
responds with (some fields must be omitted even though they are included
in the response) we have to create an intermediate struct to marshal
rules properly.

See hetznercloud/cli#725

(cherry picked from commit 16daea0)
phm07 added a commit to hetznercloud/hcloud-go that referenced this issue Apr 18, 2024
Because the Firewall API expects a different JSON formatting than it responds with (some fields must be omitted even though they are included in the response) we have to create an intermediate struct to marshal rules properly.

See hetznercloud/cli#725
phm07 added a commit to hetznercloud/hcloud-go that referenced this issue Apr 19, 2024
Because the Firewall API expects a different JSON formatting than it responds with (some fields must be omitted even though they are included in the response) we have to create another struct to marshal rules properly.

See hetznercloud/cli#725
phm07 added a commit to hetznercloud/hcloud-go that referenced this issue Apr 19, 2024
Because the Firewall API expects a different JSON formatting than it
responds with (some fields must be omitted even though they are included
in the response) we have to create another struct to marshal rules
properly.

This should be reverted once the Firewall API has consistent response
and request schemas.

See hetznercloud/cli#725
phm07 added a commit to hetznercloud/hcloud-go that referenced this issue Apr 19, 2024
Because the Firewall API expects a different JSON formatting than it
responds with (some fields must be omitted even though they are included
in the response) we have to create another struct to marshal rules
properly.

This should be reverted once the Firewall API has consistent response
and request schemas.

See hetznercloud/cli#725

(cherry picked from commit 43b2bab)
@apricote
Copy link
Member

Fixed in v1.43.1.

Thanks for the report @Dari4sho!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants