Bug #7060


clientAddress behind proxy

Added by Mark Petryk almost 5 years ago. Updated about 4 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


When I'm behind haproxy, I always get a clientAddress() of 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 approot/vault/clients/P/PETROCK (MARK) ~ C000002/aaa//classWarehouseBaseWidget__inherit__graph.md5
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=
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=

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 as well;

 21 class FileResource
 22 : public Wt::WFileResource
 23 {
 24   public:
 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;
 38       for( auto header : request.headers() )
 39       {
 40         std::cout << __FILE__ << ":" << __LINE__
 41           << " " << << "=" << header.value()
 42           << std::endl;
 43       }
Actions #1

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.

Actions #2

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$ && ./
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
INFO: Opened log file (/dev/null).

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;·
Actions #3

Updated by Mark Petryk almost 5 years ago

A little more clearly;


185   std::cout << __FILE__ << ":" << __LINE__·
186     << " " << environment().clientAddress()·
187     << " " << environment().headerValue("X-Forwarded-For")·
188     << std::endl;·
Actions #4

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.

Actions #5

Updated by Mark Petryk almost 5 years ago

I see.

Thank you for the clarification.


Actions #6

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; - - [2019-May-21 14:14:28.193] "POST /vault?wtd=P5fqM4cKUDU1KxRl HTTP/1.1" 200 76 - - [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?

Actions #7

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.

Actions #8

Updated by Keelie Dodson over 4 years ago

Actions #9

Updated by Roel Standaert about 4 years ago

  • Status changed from New to Resolved
Actions #10

Updated by Mark Petryk about 4 years ago

Thank you, sir!

Actions #11

Updated by Roel Standaert about 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF