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