POST becomes GET after ProxyPass - node.js

I have a nodejs app running inside a docker container on port 3050. If I allow the port through the firewall then everything works fine. But if I try to ProxyPass it then the app seems to receive GET instead of POST.
ProxyPass / http://localhost:3050/
When I look at the access log apache receives the request as a POST. But logging the req.method in expressjs results in GET. I have also tried loads of other settings
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://localhost:3050/
ProxyPassReverse / http://localhost:3050/
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"
The strangest thing is that I am Proxying lots of other services like gitlab and keycloak without any problem.
Could it be something to do with HTTP 1.1 or HTTP 2? Or does my httpd server have some setting messed up?

I was only testing with postman...obviously in future I should try curl or something as well. Turns out that postman has a setting "Redirect with the original HTTP method instead of the default behavior of redirecting with GET." which is turned off by default. I don't know whether the browser will behave like this but at least now it seems to be working
update:
Actually it wasn't even that setting. it was because i had not prefixed the url with https:// due to a training course which excluded the protocol because we weren't working with secure. so the httpd server proxied port 80 to 443 and postman didn't handle it correct. as i would be hitting directly https in production it shouldn't be a problem

Related

Socket.io cannot get a 101 response on Apache server only on localhost

I've been developing a web application using socket.io with Angular 2 NodeJs and Apache, on localhost everything works fine, but when I deploy my app and test it on the server I cannot get a 101 response, when the app starts a http request is made automatically by socket.io library that returns a socket id, but then it send another request that supposed to return a 101 response as ocurred on localhost but instead it returns a 400 bad request, I've been struggling with this error and I honestly don't know how to solved it after many tries configuring the virtualhost on my server I almost give up.
This is on localhost:
https://i.stack.imgur.com/PxLEN.png
and this is on my server:
https://i.stack.imgur.com/SKUqH.jpg
https://i.stack.imgur.com/10eMz.jpg
https://i.stack.imgur.com/dok4n.jpg
https://i.stack.imgur.com/KXdf5.jpg
This is my vistualhost config.
ProxyPass /sck-srv http://localhost:3007/sck-srv
ProxyPassReverse /sck-srv http://localhost:3007/sck-srv
ProxyPass /sck-srv ws://127.0.0.1:3007 retry=0 keepalive=On
ProxyPassReverse /sck-srv ws://127.0.0.1:3007 retry=0
VirtualHost port 443
I appreciate your help

Apache Reverse Proxy and localhost - "Mixed content, the content must be served over HTTPS"

I have created a reverse proxy for my node server that runs on localhost, so that it can be served over HTTPS.
The forwarding works grate, however when the app tries to make requests I get:
Mixed Content: The page at 'https://foo.com/' was loaded over HTTPS,
but requested an insecure XMLHttpRequest endpoint
'http://localhost:8888/graphql?query=%7Bnotifications(userid)%7Bid%2C…
This request has been blocked; the content must be served over HTTPS.
Vhost config:
<VirtualHost *:443>
ServerName www.foo.com
ServerAlias foo.com
DocumentRoot /var/www/foo/
ErrorLog /var/www/foo/error.log
CustomLog /var/www/foo/requests.log combined
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
SSLCertificateFile "/etc/letsencrypt/live/foo.com/cert.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/foo.com/privkey.pem"
ProxyPreserveHost On
ProxyRequests Off
ProxyPass / http://localhost:8888/
ProxyPassReverse / http://localhost:8888/
</VirtualHost>
What is missing from my setup?
You are openning the page on https://foo.com/, but URLs within your page contain hardcoded localhost domain and port. While rendering the page, client browser will try to fetch 'http://localhost:8888/graphql effectively skipping apache (which is running on port 80, on server foo.com) and hitting directly your node app, which will 1) work only if you run the browser from the very same machine where you have your node app running, and 2) even then, you will get the above error since some page assets are loaded using http.
When you use relative URLs (for example URL that begins with /), browser will prepend the base URL, resulting in https://foo.com/graphql.
Absolute vs relative URLs
You need to add a SSL certificate to your node.js app. Enabling it on apache won't help since the apache is forwarding the requests to your node.js app on port 8888 (which communicates on plain http and not https). That's why you get the mixed content error. The initial request is on https on apache then forwarded to http to node.js
Steps to configure node.js app with a SSL certificate (you can use a self-signed certificate or a commercial one).
First you have to use ssl-root-cas available via npm. The configure it as follows:
'use strict';
var https = require('https')
, cas
;
// This will add the well-known CAs
// to `https.globalAgent.options.ca`
require('ssl-root-cas').inject();
cas = https.globalAgent.options.ca;
cas.push(fs.readFileSync(path.join(__dirname, 'ssl', '01-ssl-intermediary-a.pem')));
cas.push(fs.readFileSync(path.join(__dirname, 'ssl', '02-ssl-intermediary-b.pem')));
cas.push(fs.readFileSync(path.join(__dirname, 'ssl', '03-ssl-site.pem')));
Try and see if that works!

Apache, Node, .htaccess

I have an apache webserver listening on port 80. With apache, a PHP/MySQL system based on Zend framework. And I also have a node server listening on port 3000.
When a client sends a request, always on port 80, it's therefore first handled by apache. I would like to apply the following rules before treating the request:
if content-type is "application/json" then
use apache web server
else if content-type is "application/zend" then
use apache web server
else
use node server
Here content-type is sent in the request headers. Content-type "application/zend" is a custom content-type to say that, for this type of particular request, we don't want to use node server (I need this for some reasons).
I've tried to modify httpd-vhosts.conf with
ProxyPreserveHost on
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
But that's of course not enough as not everything should be handled by the node server (listening on port 3000). Hence some rules should be added. But I'm unsure where/how. I also tried to change the .htaccess file, but not sure how either.
Any help would be great! Thanks!
This should work (in .conf file):
RewriteEngine on
RewriteCond %{HTTP:Content-type} !=application/json
RewriteCond %{HTTP:Content-type} !=application/zend
RewriteRule ^ http://%{HTTP_HOST}:3000%{REQUEST_URI} [P]
Keep in mind that this might carry a performance penalty, and if most of your requests end on node, we should perhaps search for better solution.

Access JBOSS management console remotely through Apache

I have an environment where the JBOSS server sits on a linux machine and it's services accessed via Apache server running there.
I am not able access the JBOSS console as "http://:/console"
What changes apparently will I have to make in "httpd.conf" to access this url from outside.
The safer way of accessing your JBoss console is through an ssh tunnel.
Execute locally
ssh -L 7990:localhost:9990 username#your.jboss.server -N
and enjoy your remote server's console on your local machine on port 7990.
Opening console port on your web server is also a solution, but less secure one.
Try with:
<Location /console>
ProxyPass http://localhost:9990
ProxyPassReverseCookiePath / /console/
ProxyPassReverseCookieDomain localhost <YOUR PUBLIC IP ADDRESS>
</Location>
<Location /console/>
ProxyPassReverse /
</Location>
ProxyPreserveHost On
The thing with the ProxyPassand ProxyPassReverse directives is that it preserves the domain so you can handle cookies as is on JBoss side without any problems, and that sessions are tracked correctly.
The ProxyPassReverseCookiePath directive rewrites the path string in Set-Cookie headers. If the beginning of the cookie path matches internal-path, the cookie path will be replaced with public-path. And ProxyPassReverseCookieDomain rewrites the domain string in Set-Cookie headers.
See more:
apache httpd JBoss AS 7 admin console proxy
Apache Module mod_proxy

Running Sonar behind Microsoft IIS with SSL enabled fails to redirect to https after successfull login

I have configured Sonar webserver to have all of the requests to go through Microsoft IIS server.
It was confirmed to work fine with requests via http protocol.
However, once the https was enabled, after successful login, Sonar webapp is trying to redirect to non-https url, causing it to timeout. If I then go and change the url to go to https, it shows as authenticated and continues to work as normal.
The same issue happens when you trying to logout - instead of redirecting to https page, it goes out to http.
What needs to be done to make Sonar post-login action to use the same protocol via which the login page was requested originally?
sonar.properties has:
sonar.web.host: 127.0.0.1
sonar.web.port: 9000
sonar.web.context: /sonar
IIS plugin has:
<VirtualHostGroup Name="default_host">
<VirtualHost Name="*:80"/>
<VirtualHost Name="*:9443"/>
<VirtualHost Name="*:443"/>
<VirtualHost Name="*:9000"/>
</VirtualHostGroup>
<ServerGroup Name="sonar_group">
<Server Name="sonar_server">
<Transport Hostname="127.0.0.1" Port="9000" Protocol="http"/>
</Server>
</ServerGroup>
<UriGroup Name="sonar_host_URIs">
<Uri Name="/sonar*"/>
</UriGroup>
<Route ServerGroup="sonar_group" UriGroup="sonar_host_URIs" VirtualHostGroup="default_host"/>
Thanks.
In the web UI (while logged in as an admin user), go to Settings -> General and make sure the URL listed under Server Base URL starts with "https". This can also be set in the server's sonar.properties file using sonar.core.serverBaseURL
This is a well-known issue with the Ruby stack, and requires tweaking the web-server config -- not that of Sonar. On Apache you'd have to do the following, Im sure the pointers in the ticket will also lead you to a solution for IIS:
RequestHeader set X_FORWARDED_PROTO "https"

Resources