Bug #7060
closedclientAddress behind proxy
0%
Description
When I'm behind haproxy, I always get a clientAddress() of 127.0.0.1 I know that haproxy is forwarding the IP address of the client, but the Wt app is not picking it up in clientAddress();
[2019-May-20 22:03:26.403] 11364 [/vault pNhorHhCFPBOK6Ku] [warning] "WApplication: WApplication::addMetaHeader() with no effect"
FolderExplorer/TableView.cpp:33 127.0.0.1 approot/vault/clients/P/PETROCK (MARK) ~ C000002/aaa//classWarehouseBaseWidget__inherit__graph.md5
FolderExplorer/TableView.cpp:40 Host=cms.redacted.com
FolderExplorer/TableView.cpp:40 User-Agent=Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
FolderExplorer/TableView.cpp:40 Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
FolderExplorer/TableView.cpp:40 Accept-Language=en-US,en;q=0.5
FolderExplorer/TableView.cpp:40 Accept-Encoding=gzip, deflate, br
FolderExplorer/TableView.cpp:40 Referer=https://cms.redacted.com/vault/
FolderExplorer/TableView.cpp:40 Cookie=logincookie=0t1H00UdKfS19SMnt1hLgQQwQ0OzKTa4; _ga=GA1.2.1552206788.1555591994
FolderExplorer/TableView.cpp:40 Upgrade-Insecure-Requests=1
FolderExplorer/TableView.cpp:40 X-Forwarded-For=71.170.246.90
The docs indicate that "This is taken to be the first public address that is given in the Client-IP header, or in the X-Forwarded-For header" This 'ip address loggin' also pops out on the console as 127.0.0.1 as well;
21 class FileResource
22 : public Wt::WFileResource
23 {
24 public:
25
31 void handleRequest( const Wt::Http::Request & request, Wt::Http::Response & response )
32 {
33 std::cout << __FILE__ << ":" << __LINE__
34 << " " << request.clientAddress()
35 << " " << fileName()
36 << std::endl;
37
38 for( auto header : request.headers() )
39 {
40 std::cout << __FILE__ << ":" << __LINE__
41 << " " << header.name() << "=" << header.value()
42 << std::endl;
43 }
44
Updated by Roel Standaert almost 5 years ago
It appears that the handling of this is at the moment only done in WEnvironment (at least when using wthttp), and you'd have to check X-Forwarded-For yourself in handleRequest of a WResource. It looks like the docs don't match the implementation there.
Updated by Mark Petryk almost 5 years ago
Thank you, Roel.
When running the app, the envronment().clientAddress() also still reports the 127...1. I was assuming it was coming from the same source module.
I shouldn't even be posting this here, I should just fix it myself, eh?
developer@rtmus2:~/projects/artecams/build$ make.sh && ./doit.sh
Scanning dependencies of target artecams
[ 1%] Building CXX object CMakeFiles/artecams.dir/src/AppVault.cpp.o
[ 2%] Linking CXX executable artecams
[100%] Built target artecams
running
INFO: Opened log file (/dev/null).
/home/developer/projects/artecams/src/AppVault.cpp:185 127.0.0.1
From this code:
182 Rtm::AppVault::AppVault( const Wt::WEnvironment & env )·
183 : AppBase( "artecams.vault.sqlite", env )·
184 {·
185 std::cout << __FILE__ << ":" << __LINE__ << " " << environment().clientAddress() << std::endl;·
Updated by Mark Petryk almost 5 years ago
A little more clearly;
/home/developer/projects/artecams/src/AppVault.cpp:185 127.0.0.1 71.170.246.90
185 std::cout << __FILE__ << ":" << __LINE__·
186 << " " << environment().clientAddress()·
187 << " " << environment().headerValue("X-Forwarded-For")·
188 << std::endl;·
Updated by Roel Standaert almost 5 years ago
If WEnvironment is also reporting the wrong address, that must be because you didn't set <behind-reverse-proxy> to true in wt_config.xml.
Wt does not look at X-Forwarded-For by default. It only looks at that header if you explicitly told it it's behind a reverse proxy. Otherwise, anyone could impersonate any IP address by putting that in X-Forwarded-For. So you should enable behind-reverse-proxy and make sure that the application can only be accessed through the proxy, otherwise spoofing would be possible.
Updated by Mark Petryk almost 5 years ago
I see.
Thank you for the clarification.
~mark
Updated by Mark Petryk almost 5 years ago
Roel, since I have you here, one thing I have been curious about...
I was unaware of the behind_reverse_proxy option in the config. Turning on that allows clientAddress() to report the proper IP address. Thank you for that!
I'm also curious about the output from these lines;
127.0.0.1 - - [2019-May-21 14:14:28.193] "POST /vault?wtd=P5fqM4cKUDU1KxRl HTTP/1.1" 200 76
127.0.0.1 - - [2019-May-21 14:14:28.321] "GET /vault/ HTTP/1.1" 200 2326
Would not these log output lines also benefit from the reverse proxy setting?
Updated by Roel Standaert almost 5 years ago
Yeah... maybe they should. At the moment all of the X-Forwarded-For handling happens only in WEnvironment. It has bothered me too that the access log doesn't take that into account.
Updated by Roel Standaert about 4 years ago
- Status changed from Resolved to Closed