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

[BUG] Widgets are not sending X-Api-Key and Authorization headers #1549

Closed
5 tasks done
mjlehrke opened this issue Apr 24, 2024 · 7 comments
Closed
5 tasks done

[BUG] Widgets are not sending X-Api-Key and Authorization headers #1549

mjlehrke opened this issue Apr 24, 2024 · 7 comments
Assignees
Labels
🐛 Bug [ISSUE] Ticket describing something that isn't working

Comments

@mjlehrke
Copy link

Environment

Self-Hosted (Docker)

System

Firefox 125.0.2

Version

3.0.0

Describe the problem

Summary: Widgets are not sending the X-Api-Key and Authorization headers.

This is based on troubleshooting the issue I posted in the 3.0.0 discussion #1537 (comment)

Description: After upgrading to version 3.0.0 I noticed that my HealthChecks and Uptime-Kuma widgets were no longer working and failed with "Proxy returned error from target server". Looking in the console log (attached below), the proxy server was getting a 401 error from HealthChecks. Both HealthChecks and uptime-kuma servers are running on my local network and were working in Dashy version 2.1.2. After troubleshooting I've come to the conclusion that Widgets are not sending appropriate key/auth headers to the server endpoints. Both non-working widgets are supposed to send a header with this.makeRequest(this.endpoint, authHeaders). However, those headers are not being sent. The Weather widget works fine, which makes sense because for that widget, the apiKey is appended to the url instead. It appears the headers are being sent to the Dashy cors proxy, but they are not being forwarded to the server. Details below.

Troubleshooting: I set up a new instance of Dashy using the default config to make sure nothing in my config was wrong (see example below), but it still had the proxy error. Using curl to query the endpoint from the host returns the proper response. Additionally, querying the endpoint within the Dashy container returned a correct response using docker exec -it dashy curl -H "X-Api-Key: yMu9uTiVQDCWas3hnRwlWTm22kAc4APY" http://192.168.0.150:3002. Finally, attempting the request in Firefox with the "Allow CORS" addon activated still failed.

Indeed, HealthChecks was rejecting the request with a 401 error:

    04/24/2024
    04:14:18 AM
    [pid: 188|app: 0|req: 1815/1886] 192.168.48.1 () {28 vars in 397 bytes} [Wed Apr 24 04:14:18 2024] GET /api/v1/checks => generated 0 bytes in 3 msecs (HTTP/1.1 301) 6 headers in 219 bytes (1 switches on core 0)
    04/24/2024
    04:14:18 AM
    [pid: 188|app: 0|req: 1816/1887] 192.168.48.1 () {28 vars in 399 bytes} [Wed Apr 24 04:14:18 2024] GET /api/v1/checks/ => generated 28 bytes in 1 msecs (HTTP/1.1 401) 11 headers in 374 bytes (1 switches on core 0)


These pieces of evidence led me to believe it was an issue with Dashy.

I intercepted the request and found that the X-Api-Key header was not being sent to the HealthChecks endpoint. These are the intercepted headers sent to HealthChecks, note the absence of the X-Api-Key header that should contain the apiKey passed in the config:

{
    accept: 'application/json, text/plain, */*',
    'user-agent': 'axios/1.6.8',
    'accept-encoding': 'gzip, compress, deflate, br',
    host: '192.168.0.150:3002',
    connection: 'keep-alive'
}

Interestingly, the x-api-key header was being sent to the Dashy cors proxy when looking in the console log, but was not being forwarded on:

GET /cors-proxy HTTP/1.1
Host: 192.168.0.150:4000
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.0.150:4000/
target-url: http://192.168.0.150:3002/api/v1/checks
x-api-key: yMu9uTiVQDCWas3hnRwlWTm22kAc4APY
DNT: 1
Connection: keep-alive

Additional info

Deprecation warning: The simple-icons entrypoint will be removed in the next major. Please switch to using import * as icons from "simple-icons/icons" if you need an object with all the icons. index.js:1:8

Dashy V3.0.0 🚀 CoolConsole.js:6:10

XHRGET
http://192.168.0.150:4000/cors-proxy
[HTTP/1.1 500 Internal Server Error 16ms]

{
  "error": {
    "message": "Request failed with status code 401",
    "name": "AxiosError",
    "stack": "AxiosError: Request failed with status code 401\n    at settle (/app/node_modules/axios/dist/node/axios.cjs:1966:12)\n    at IncomingMessage.handleStreamEnd (/app/node_modules/axios/dist/node/axios.cjs:3065:11)\n    at IncomingMessage.emit (node:events:530:35)\n    at endReadableNT (node:internal/streams/readable:1696:12)\n    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)\n    at Axios.request (/app/node_modules/axios/dist/node/axios.cjs:3876:41)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)",
    "config": {
      "transitional": {
        "silentJSONParsing": true,
        "forcedJSONParsing": true,
        "clarifyTimeoutError": false
      },
      "adapter": ["xhr", "http"],
      "transformRequest": [null],
      "transformResponse": [null],
      "timeout": 0,
      "xsrfCookieName": "XSRF-TOKEN",
      "xsrfHeaderName": "X-XSRF-TOKEN",
      "maxContentLength": -1,
      "maxBodyLength": -1,
      "env": {},
      "headers": {
        "Accept": "application/json, text/plain, */*",
        "User-Agent": "axios/1.6.8",
        "Accept-Encoding": "gzip, compress, deflate, br"
      },
      "method": "get",
      "url": "http://192.168.0.150:3002/api/v1/checks",
      "json": {}
    },
    "code": "ERR_BAD_REQUEST",
    "status": 401
  }
}
GET /cors-proxy HTTP/1.1
Host: 192.168.0.150:4000
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.0.150:4000/
target-url: http://192.168.0.150:3002/api/v1/checks
x-api-key: yMu9uTiVQDCWas3hnRwlWTm22kAc4APY
DNT: 1
Connection: keep-alive

⚠️ Warning ⚠️
Proxy returned error from target server

This is likely not an issue with Dashy, but rather your configuration.
If you think it is a bug, please open a ticket on GitHub: https://git.io/JukXk CoolConsole.js:11:10

Stack Trace
Request failed with status code 401 CoolConsole.js:18:12

Uncaught (in promise) TypeError: t.checks is undefined
    processData HealthChecks.vue:80
    fetchData HealthChecks.vue:72
    promise callback*dac2/fetchData/< HealthChecks.vue:71
    fetchData HealthChecks.vue:69
    mounted WidgetMixin.js:26
    VueJS 25
    o WidgetBase.vue:1
    VueJS 24
HealthChecks.vue:80

Please tick the boxes

@mjlehrke mjlehrke added the 🐛 Bug [ISSUE] Ticket describing something that isn't working label Apr 24, 2024
@alayham
Copy link
Contributor

alayham commented Apr 25, 2024

Confirmed with my Proxmox list widget. The reason is a change or a bug in the internal API. Most probably related to this commit
f353780

It looks like that the widget mixin used to collect all headers passed to the makeRequest method in a CustomHeaders header that is passed to the cors-proxy. This is broken now, and no headers are passed to the cors-proxy.

I confirmed the bug by manually passing the CustomHeaders header like this

    authHeaders() {
      if (this.userName && this.tokenName && this.tokenUuid) {
        const auth= { Authorization: `PVEAPIToken=${this.userName}!${this.tokenName}=${this.tokenUuid}` }
        return { CustomHeaders: JSON.stringify(auth)};
      }
      return false;
    },

I can send a PR for my widgets, but before that I think @Lissy93 should have a look at the code, and decide whether the widgets should be responsible for this CustomHeaders, or the mixin will be fixed to take care of it.

@Lissy93
Copy link
Owner

Lissy93 commented Apr 29, 2024

Thanks @alayham - this should be fixed in 3.0.1

@Lissy93 Lissy93 added the 🚏 Awaiting User Response [ISSUE] Response from original author is pending label Apr 29, 2024
@liss-bot liss-bot removed the 👤 Awaiting Maintainer Response [ISSUE] Response from repo author is pending label Apr 29, 2024
@mjlehrke
Copy link
Author

mjlehrke commented May 3, 2024

I'm still seeing the issue in 3.0.1.

@liss-bot liss-bot added 👤 Awaiting Maintainer Response [ISSUE] Response from repo author is pending and removed 🚏 Awaiting User Response [ISSUE] Response from original author is pending labels May 3, 2024
@alayham
Copy link
Contributor

alayham commented May 5, 2024

@Lissy93 I have Confirmed that the issue still exists in the latest commit, and that my patch above resolves it for my Proxmox widgets.

@liss-bot liss-bot removed the 👤 Awaiting Maintainer Response [ISSUE] Response from repo author is pending label May 6, 2024
@Lissy93 Lissy93 closed this as completed in b97ba74 May 9, 2024
@Lissy93
Copy link
Owner

Lissy93 commented May 9, 2024

Should be fixed in #1576 :)

@CrazyWolf13
Copy link
Collaborator

Confirmed, the fix resolved the issue for me.

@mjlehrke
Copy link
Author

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 Bug [ISSUE] Ticket describing something that isn't working
Projects
Status: Done
Development

No branches or pull requests

5 participants