- A running Apache server. A basic installation would do.
- Access to the Apache httpd.conf file (found in the /conf directory under Apache’s installed directory
- Ability to restart the Apache server
- A portal, or any other application running on the J2EE WAS
- Administrator access to the J2EE WAS (specifically — access to the Visual Administrator tool)
- A smile on your face and a song in your heart (optional, Apache does not require those; nonetheless these are highly recommended for happy living)
Overview — How it’s going to happen
We will use mod_proxy, Apache’s Proxy module. mod_proxy lets you create forward (A.K.A “regular”) and reverse proxies. We will make sure the module (and its sub-modules) are loaded, and configure it to allow only reverse-proxying from specific URL patterns to the internal server we’re proxying.
On the portal/J2EE side we will use the PortMapping feature (you can read a short description of this property in the The Reverse Proxy Series — Part 2: IIS as a reverse-proxy in this series, near the end of the post) to make sure redireect URLs sent to the client don’t point to the internal server.
Step 1 — Load the modules
Open httpd.conf in your favourite text editor (I use jEdit because it highlights the file’s syntax; notepad would also do; VI if you’re 1337 ;-)). You can find it under the /conf directory where Apache is installed (in a deafult Windows installation that would be
Program FilesApache GroupApache2conf).
Rule of thumb in most UNIX or UNIX-originated configuration files — a hash (“#”) denotes a remark. You can see all kinds of lines starting with “#” — those are disabled lines. What we’re looking for are the lines which load mod_proxy and mod_proxy_http (the sub-module which handles the HTTP protocol for proxying). Do a search for “mod_proxy.so” and you’re most likely to find the following line:
#LoadModule proxy_module modules/mod_proxy.so
Simply remove the “#” from the start of the line to enable loading mod_proxy. To do same for the LoadModule line for mod_proxy_http (if there’s no “#” in the begining of the line it means the module is already loaded.)
You should now have the following two lines in your
LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so
Step 2 — Activate mod_proxy, and configure basic reverse-proxy functionality
That takes care of loading the modules. Now to configure them to something useful, add the following lines at the end of the configuration file (replace “internal.company.com:50000” with the host-name and port of your internal portal, and “external.company.com” with the host-name of the revere-proxy server)
#Enable reverse-proxying ProxyVia on ProxyTimeout 600 #disable forward-proxying ProxyRequests Off #proxy /irj both ways ProxyPass /irj http://internal.company.com:50000/irj ProxyPassReverse /irj http://external.company.com/irj #proxy /logon both ways ProxyPass /logon http://internal.company.com:50000/logon ProxyPassReverse /logon http://external.company.com/logon
What are all those directives?
ProxyVia on— turns on reverse-proxying
ProxyTimeout 600— sets mod_proxy’s time-out for requests
ProxyRequests off— disables forward-proxying — this is extremely important to do! if you don’t set ProxyRequests to “off” users will able to use your Apache server to as a proxy — I can’t stress enough how much that would be bad.
ProxyPass /irj http://internal.company.com:50000/ irj
-- Tells mod_proxy to reverse-proxy all requests begining with /irj to the internal proxy
ProxyPassReverse /irj http://external.company.com /irj-- Tells mod_proxy to make sure redirects sent via HTTP headers from the internal server are sent as redirects to the reverse- proxy host-name and not the internal server's name
(the ProxyPass and ProxyPassReverse for /logon are similar to the lines handling /irj; to see why this is needed refer to the The Reverse Proxy Series — Part 2: IIS as a reverse-proxy of this series)
Step 3 — Configuring PortMappings in the WAS
If you were to try using the reverse-proxy at this stage, you’ll see you get redirected to the internal portal at a very early stage (probably after you try to submit your user-name or password). To stop this from happening we have to use the WAS J2EE’s PortMapping proprety to make sure redirects are not made to the internal server, but to the reverse-proxy instead. You can read more about this in the The Reverse Proxy Series — Part 2: IIS as a reverse-proxy — follow the instruction given there (it’s the same process). UPDATE: In most cases it should be enough to make Apache preserve the “Host:” header when proxying the requests. This is done by setting the ProxyPreserveHost attribute of mod_proxy to “On”. If you set this you can probably get by without touching the PortMapping feature of the WAS..
Step 4 — Rejoice, for thou are done!
Test it! Restart Apache (if you haven’t done that already), and navigate to /irj on the reverse-proxy’s host-name — you should be seeing the portal from the internal server. Yeah baby, yeah.
This takes care of simple scenarios. But what happens if you have all kinds of back-end systems to reverse-proxy as well? What about SSL? We’ll have a look at the infamous mod_rewrite (here’s a quote about it: “Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo.” — I see you can tell it’s gonna be f-u-n), and we’ll see what needs to be done to add SSL support to the reverse-proxy scenario.