On Mon, Jul 2, 2012 at 9:01 AM, Clinton J. Campbell < [email protected]> wrote:
> Thanks Daniel (and others) for the help along the way. I've landed on > pretty much the same conclusion as I've continued researching. The > additional insight about the redirects helped me craft my searches more > specifically. I figure I ought to share some of my conclusions for anybody > who might stumble upon this thread in their own searches later. > > I only mentioned one of the scenarios giving me trouble in detail, but > there are actually three distinct problems now that I know the redirects > are originating at the application level. > > Joomla Administration -- It looks like my best options will be #1 from > Daniel's reply (adjust application behavior) or #3 (use backend SSL > connection to trick the application). Option #3 will require additional > virtual hosts and the challenge will be ensuring the proxy directs the > traffic properly between the encrypted and unencrypted instances. If I > happen to send unencrypted traffic to the encrypted backend, I'm afraid I > might end up with similar redirects causing undesirable behavior. The > workload on these servers is relatively low, so I'm leaning toward #3 since > it will minimize the administrative burden going forward. > > Joomla Plugins (extplorer) -- I'm hopeful that option #3 will resolve my > issues for Joomla plugins, though I may need to look more deeply into > option #1 here as well. > > WebDAV -- I believe I'm limited to option #2 (rewrite the response at the > proxy) and option #3. Again I'm leaning toward #3 since it is the easiest > administratively. If the traffic load increases down the road, I may > reconsider. > > Finally, here are some references I intend to consult as I go forward: > > http://stackoverflow.com/questions/1110710/webdav-behind-a-reverse-proxy > > http://serverfault.com/questions/121766/webdav-rename-fails-on-an-apache-mod-dav-install-behind-nginx > > http://serverfault.com/questions/17239/joomlas-extplorer-ssl-seems-to-be-broken?rq=1 > http://forum.joomla.org/viewtopic.php?p=1776489 > > http://www.turnkeylinux.org/forum/support/20101213/fileserver-appliance-behind-forwarding-proxy > > > On Sunday, July 1, 2012 at 11:01 AM, Daniel Ruggeri wrote: > > > On 7/1/2012 2:40 AM, Clinton J. Campbell wrote: > > > I know that this is not an unusual combo, fronting an unencrypted > httpd with a proxy accepting connections over https, and the server seems > to handle receiving https URI's within headers for GET requests. So I guess > I'm still curious whether there is a way to configure httpd to prevent the > redirection to http on the POST? > > > > > > There's one remaining twist in the logs, that also makes me wonder if > the problem is coming from Joomla. I ran a scenario lifting the restriction > to https and I connected unencrypted to the server. After the POST, the > server responds in the same fashion, with an HTTP 303. Is this a standard > pattern for httpd with POST requests or is it something that is likely > being triggered by the application? > > > > Yes, I think you are getting closer. The important distinction to make > > is that httpd is not authenticating the user - it's the application > > (Joomla) running inside httpd. I have seen this before in other > > applications that generate a URL for redirects or links based on the > > connection it received. Luckily, in my case, I was able to trick the > > backend container into thinking it's speaking https by setting some > > headers. It sounds like the application is receiving the credentials and > > then just sending along the redirect for the user to make it to the > > admin landing page. Unfortunately, it's using the scheme (http) used > > when talking to httpd as part of that location header rather than > > creating a relative or server-relative redirect. > > > > In this scenario, there are three options. > > *Adjust how the application behaves (there may be a config setting > > controlling this) > > *Modify the response as it passes through one of the two proxies. In > > httpd, we would use ProxyPassReverse for this situation - not sure what > > Squid has > > *Self-sign and install some certs on the 'inside' httpd instance so it > > will be over SSL (thus tricking the app) > > > > The challenge with the second option is that you might solve this > > particular problem but could create new ones or find another stumbling > > block one step further into the process... and the next thing you know > > you may have a mess of complicated config settings you don't want to > > touch in the future for fear of breaking something. > > > > -- > > Daniel Ruggeri > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] (mailto: > [email protected]) > > For additional commands, e-mail: [email protected] (mailto: > [email protected]) > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > Or just dump Squid which seams is not appropriate for your Joomla case and use Apache instead. It takes 15 minutes to set Apache as reverse proxy.
