NginxProxyManager / NginxProxyManager/nginx-proxy-manager
Sending Underscores in your header NPM
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 34.2k
- Forks
- 3.9k
- Avg merge
- 21h 12m
- Merged PRs (30d)
- 20
Description
The bug
NPM is causing problems with some software, such as Chatwoot, as it does not send Underscores in its header.
However, I didn't identify any way to fix this via the interface.
This is a similar bug, however, with some differences: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1731
Nginx Proxy Manager Version
v2.10.4
To Reproduce
Steps to reproduce the behavior:
Using Chatwoot as an example.
- Access Postman
Create a GET request to the API: - Add authorization of type: Api Key with the parameters:
Key: api_access_token
Value: YOUR_KEY
Add to: Header - See error
Expected behavior
Return 200 with json payload
Additional context
Below is what I receive in Chatwoot when I make a request to the API.
The same error occurs when trying to connect the Evolution API to Chatwoot.
Chatwoot Log
I, [2024-01-08T20:45:37.526502 #1] INFO -- : source=rack-timeout id=ae362ea3-c711-4e4f-a35a-785f48f6e9bb timeout=15000ms state=ready
I, [2024-01-08T20:45:37.527204 #1] INFO -- : [ae362ea3-c711-4e4f-a35a-785f48f6e9bb] Started GET "/api/v1/accounts/1/inboxes" for 10.0.0.2 at 2024-01-08 20:45:37 +0000
I, [2024-01-08T20:45:37.531310 #1] INFO -- : [ae362ea3-c711-4e4f-a35a-785f48f6e9bb] Processing by Api::V1::Accounts::InboxesController#index as JSON
I, [2024-01-08T20:45:37.531415 #1] INFO -- : [ae362ea3-c711-4e4f-a35a-785f48f6e9bb] Parameters: {"account_id"=>"1"}
I, [2024-01-08T20:45:37.532654 #1] INFO -- : [ae362ea3-c711-4e4f-a35a-785f48f6e9bb] Filter chain halted as :authenticate_user! rendered or redirected
I, [2024-01-08T20:45:37.532852 #1] INFO -- : [ae362ea3-c711-4e4f-a35a-785f48f6e9bb] Completed 401 Unauthorized in 1ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 361)
I, [2024-01-08T20:45:37.533162 #1] INFO -- : source=rack-timeout id=ae362ea3-c711-4e4f-a35a-785f48f6e9bb timeout=15000ms service=7ms state=completed
Fix
To fix the issue, the steps below were necessary.
- Within the NPM panel, in the Proxy Host edition, activate the Websockets support function.
2 ) In the Custom locations tab, we add a new location / and apply proxy_pass_request_headers on;
So far, so good.
The problem with NPM starts here.
3) Access the server's FTP, and the folder where the hosts' records are located:
In my case /var/lib/docker/volumes/proxy_data/_data/nginx/proxy_host
-
Access the registry corresponding to the host you want to modify and add: underscores_in_headers on;
just below: listen [::]:443 ssl http2;
-
Save and restart the NPM service
After that, the error no longer occurs.
What do I want?
It would be very important to be able to modify the header information directly via the interface, such as adding the item: underscores_in_headers on;
Without needing to access the server via FTP.
Because when this is done, any change we make to the NPM dashboard overwrites the file, erasing what we did.
Also, there is no need to restart the application to apply the correction.
Is this possible? Apply adjustments to
Server {
}
directly via Dashboard, so we don't have to apply via FTP and lose it when we update the record?
And can we also apply adjustments globally to NPM via file or via Dashboard?
There are some adjustments that would be very interesting to be able to apply globally.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Proxy Host editor and the generated files under the proxy_host directory, focusing on the server block that currently requires manual editing. Define how the underscores_in_headers directive should be persisted through dashboard changes, then verify that regeneration does not erase it and that the resulting Chatwoot request returns the expected response.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- nginx
- Domain
- infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100