Jersey + Grizzly behind Apache reverse proxy - Resource not found - apache

I am having a jersey based REST Application which is running on grizzly and configured it as follows behind an apache reverse proxy
e.g. www.example.com/base/json/helloworld/get should redirect to my REST service. (Multiple Resources). However, when I try to open the url in the browser I always get a Resource not found.
In my apache config:
ProxyPass /base/ http://localhost:8123/
ProxyPassReverse /base/ "http://localhost:8123/
My grizzly server configuration is really simple and works if I do a curl request: curl localhost:8123/base/json/helloworld/get => Response is correct.
However, if I acess the url in my browser, e.g.
example.com/base/json/helloworld I am getting the grizzly error:
Resource identified by path /json/helloworld/get', does not exist.
HttpServer server = GrizzlyHttpServerFactory.createHttpServer(URI.create(http://localhost:8123/base), resourceConfig, false);
Am I missing something? I already tried changing the url to the domain and so on, but I can't get my head around why it doesn't work.

I found my fault. In the grizzly server my url was configured with the path /base/, but the Proxy Pass did not include the /base/ path at the end of the url. Now it works fine.

Related

How to use Apache to redirect requests for Node-Red?

I'm running in AWS a Ubuntu with a docker server (managed by Portainer) with this two running containers:
1 - NodeRed (Serving my APIs)
2 - Apache (Hosts the site that consumes the APIs from NodeRed above)
I've configured a domain to this server and setted apache to work with SSL. The apache is running ok with my site through HTTPS, but the problem is that the NodeRed (that runs in port 1080) is not configured to run in SSL. This causes a malfunction in my website since that my API endpoints are being running under HTTP and being blocked by the browser due security reasons.
The question is: is there a way to create some kind of "mapping" in apache that receives the request from HTTPS and redirect to the NodeRed in HTTP (the two are running in same server)?
My idea is to create a subdomain like https://api.mysite.com that sends the request for apache and then apache redirects it to my NodeRed. Is that possible?
There is no need to expose the API to the outside world if you don't want to. Since your apache is running correctly and both containers are running on the same host, just use proxy to forward API requests to the API container.
You can achive this by add two lines to your apache config i.e.
ProxyPass /api/ http://127.0.0.1:1080/
ProxyPassReverse /api/ http://127.0.0.1:1080/

Alfresco Share login error behind reverse proxy

I configure my Alfresco instance to be in a sub-URI (www.example.com/prefix/alfresco , www.example.com/prefix/alfresco/share) and all looks to be fine except that I can't log in Shared. The Catalina.out log this error:
ERROR [alfresco.web.site] [http-apr-28080-exec-10]
javax.servlet.ServletException: Possible CSRF attack noted when
asserting referer header
'http://www.example.com/prefix/alfresco/share/page/'. Request: POST
/prefix/alfresco/share/page/dologin, FAILED TEST: Assert referer POST
/prefix/alfresco/share/page/dologin :: referer:
'http://www.example.com/prefix/alfresco/share/page/' vs server &
context: http://10.140.8.144/ (string) or (regexp)
Then the browser show me this page (www.example.com/prefix/alfresco/share/dologin):
Something's wrong with this page...
We may have hit an error or something might have been removed or
deleted, so check that the URL is correct.
Alternatively you might not have permission to view the page (it could
be on a private site) or there could have been an internal error. Try
checking with your Alfresco administrator.
If you're trying to get to your home page and it's no longer available
you should change it by clicking your name on the Alfresco toolbar.
I tried to deactivate the CSRF filter in share-config-custom.xml, but then I can't log and I don't have any message in the log, the login page show:
Your authentication details have not been recognized or Alfresco may
not be available at this time.
My apache conf:
ProxyPass /prefix/alfresco
http://10.140.8.144:28080/prefix/alfresco ProxyPassReverse
/prefix/alfresco http://10.140.8.144:28080/prefix/alfresco
ProxyPass /prefix/alfresco/share
http://10.140.8.144:28080/prefix/share ProxyPassReverse
/prefix/alfresco/share http://10.140.8.144:28080/prefix/share
I could log before configure Alfresco for work in the reverse proxy.
There is no need to deactivate the CSRF filter. If you changed the context path as described in the documentation you need to make sure that the tomcat connector "knows" the outside context (hostname, port, context).
Either
set proxyName and proxyPort
set RemoteIpValve in tomcat server.xml and set required proxy header
variables in apache (x-forwarded-for, x-forwarded-by,
x-forwarded-proto)
use proxy_ajp instead of proxy_http and define a ajp connector in
tomcat

Drupal - Mixed content error when using ssl certificate

I had a drupal installation working fine. I tried to migrate that one on a Docker Container runing behind a nginx reverse proxy. Everything seems fine but i have some .js and .css files that can't load because in drupal they are linked with http. The error is:
Mixed Content: The page at https://proxy.xx.xx/ was loaded
over HTTPS, but requested an insecure stylesheet
http://proxy.xx.xx/sites/default/files/css/css_xE-rWrJf-
fncB6ztZfd2huxqgxu4WO-qwma6Xer30m4.css'. This request has been
blocked; the content must be served over HTTPS.
I have something like 7 of them and i can't find where those files are called in drupal or how to change the http to https.
Best regards.
Alright, so I got to work by adding the following to the Drupal settings.php:
$conf['reverse_proxy'] = TRUE;
$base_url = 'https://whatever-your-domain-is.com';
$conf['reverse_proxy_addresses'] = array('internal_nginx_proxy_ip');
$conf['reverse_proxy_header'] = 'HTTP_X_FORWARDED_FOR';
This works for jwilder's nginx-proxy container(s) together with JrCs' letsencrypt companion container. The nginx container is handling the HTTPS/SSL (certificates) and talks HTTP with the Drupal-container internally. The Drupal container only needs to be run with the 3 ENV VARS VIRTUAL_HOST, LETSENCRYPT_HOST, LETSENCRYPT_EMAIL for everything to be set up and work its magic.
Only downside: The Drupal container's apache logs show the internal IP of the nginx proxy. But the nginx logs show the correct client IPs and Drupal apparently gets them right as well, so it's only a minor nuisance for me.
I guess the additions to the settings.php should also be applicable to custom/manual setups.
We found what was wrong. Drupal was communicating with the Nginx proxy without ssl. Some config and it was ok.

reverse proxy apache to localhost server

I've got a web app running on localhost:3000. I also have an apache server. I would like to reverse proxy the apache server so that requests to /mywebapp get forwarded to the server running on localhost:3000.
I currently have the following config at the bottom of my httpd.conf file, but I'm getting a server error when I try to access it:
ProxyPass /mywebapp http://localhost:3000
ProxyPassReverse /mywebapp http://localhost:3000
Edit - further details:
I'm running a jetty server with java -jar myapp.jar. I'd like to forward requests to an apache server listening on :80 to the jetty server.
I've got mod_proxy_http.so and mod_proxy.so enabled.
I can tell the server is running on localhost - it responds to curl with the appropriate http response. So I'm pretty sure the issue is with my apache setup, but I can't think what the problem would be.
Apache conf file in conf.d for reference: http://pastebin.com/vhXwjbQe
And I've got this in my httpd.conf:
Include conf.d/*.conf
It's hard to give a generic answer because every situation is different so here are some debugging questions to ask yourself:
if the protocol and port correct on the internal service, http and 3000.
Is the service actually listening for connections from localhost? is it running in a docker container etc that would require it to be listening on a different interface? You can check for this by looking at the output from mywebapp's logs and see if the request are making it through the proxy.
Do the paths on the internal service include the prefix that is being passed to Apache or does apache need to strip these off. if for instance mywebapp expects the path "/foo/bar" and apache's reverse proxy is sending it with the context path included "/mywebapp/foo/bar" then it will not match any path in mywebapp.

Tomcat serving URLs wrong with mod_proxy and apache

I've set up a host with apache to serve static pages and to use Tomcat to serve my web application (See this question). The static pages are server from
"http://myhost.com"
and the dynamic (tomcat) pages are server from
"http://myhost.com/myapp"
The mod_proxy makes sure the "http://myhost.com/myapp" are forwarded to tomcat server running on "http://myhost.com:8080".
The problem is that now you get the standard Tomcat introduction page on "http://myhost.com/myapp" but if you click on a local link (e.g. 'Status') on the left, it generates an URL
"http://myhost.com/manager/status" while it should generate: "http://myhost.com/myapp/manager/status"
(The same is true for webapps installed under tomcat)
What should be changed in my configuration (apache, tomcat?) to redirect my tomcat links to the right place?
Have you set the ProxyPassReverse setting in your httpd.conf. This will overwrite the HTTP Header an you'll get to the correct request on the side of tomcat.
Your URLs are mapped from:
http://myhost.com/myapp -> http://myhost.com:8080
This means that accessing the above URL will be mapped to the ROOT application in Tomcat. The ROOT application will generate pages that contain links from Tomcat's root context.
In other words, if you go to:
http://myhost.com:8080
you will get a page that contains links to
http://myhost.com:8080/manager/status
This link will work. However when that page is given back to a browser that requested it via Apache, the full URL then looks like: http://myhost.com/manager/status
I assume that you intend to deploy an application called 'myapp' to Tomcat? If that is the case the Tomcat URL for this app will be
http://myhost.com:8080/myapp
Which will also work be mapped correctly when accessed via Apache.
If you absolutely must access Tomcats root application in this way you'll have to rewrite the URLs it outputs in the pages it returns.
I've had the most success with mod_proxy_ajp. It requires mod_proxy, but works over ajp. Using it instead, your conf file looks similar
ProxyPass / ajp://localhost:8009/
See my similar question and also the answer to this question. The only fault in mod_proxy_ajp that I've found is that if I need to restart tomcat I have to force an apache restart too.