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
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx (mailto:users-unsubscribe@xxxxxxxxxxxxxxxx)
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
>
>
> ---------------------------------------------------------------------
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx (mailto:users-help@xxxxxxxxxxxxxxxx)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|