I’m working on setting up a test system at work. The system is a test environment for a major upgrade of an existing Web Application used across campus. As such, we’re testing all the fiddly bits, getting it hooked up to the ERP system, make sure single sign on and SSL termination is working right, etc.
The initial setup went well, but noticed that there were some strange behaviors here and there:
1) Javascript was broken in chrome
2) JSON errors on some pages, mostly that had an upload/drag-n-drop widget on them.
A quick F12, to bring up the net console in firebug, quickly revealed, that I was getting 503 errors for certain resources on the page. I also noticed that though I was browsing the site in https, some includes from the css were being requested over http, getting an http->https redirect from the SSO reverse proxy and ending in a 503. That mostly explained the issues above. Chrome just wasn’t having any of that, and FF sort of soldiered on and gave you a mostly working page.
This application is a php app and employs a fairly standard config.php in the docroot to setup the db connection, variables for the site, etc. A quick look through the config.php, showed that in fact, I had defined the webroot at http://footest.bar.edu, instead of https://footest.bar.edu.That explained the http includes from the css. a few keystrokes: [a s [esc]:wq!] and done, No Big Deal™.
Back to my Browser, hit F5 and…the site is completely broken, with a message to the effect of, “Sorry, you can only browse this site in https!”. We used to make fun of my Grandpa for yelling at the TV. I’m sure my kids and grandkids will make of me for yelling at my terminal sessions. So I recheck the config file. Nope, everything is correct, including the parameter which tells the software that it’s behind an SSL proxy. Changing the value of the $sslproxy from true to false and back again, doesn’t have any effect…curious.
At this point, I lept down the rabbit hole. I tried changing all the $webroot, $reverseproxy and $sslproxy variables to any value I could think of. The only thing that had any effect was the webroot, which either broke javascript, or the entire site. After some amount of time doing the same thing and hoping for a different result, I started to dig into the code (Yay opensource!). I traced the issue down the url validation code, (which is a total wtf in itself). The developers of this product, are concerned with a couple of things. 1) That you’re going to access the site over http accidentally, when you should be over https. This is a valid security concern. 2) That you are never ever going to access the software by any url other than which is defined in the config. This is paranoid. To the point, that there was a completely infuriating comment in part of the validation code that read,
// hopefully this will stop all those "clever" admins trying to set up product
// with two different addresses in intranet and Internet
I’m sorry, there is no argument you can make to me where I shouldn’t allowed to configure access under as many different urls as I want. Oh! It’s because you’re hardcoding links and references in the database based on the defined $webroot? Your product is broken. absolute URLS have no place in a modern dynamic web application.
Anyway, that aside, I found that this url validation block was executing, though it was wrapped in a if (empty($sslproxy)) block, meaning that if the $sslproxy variable was set, this should not execute. So, I added some debug code to the function and determined that as far as the code was concerned, when this function was called, $sslproxy was not set.
Curiouser and Curiouser!
Okay, back to the config, lets step through and…wait a minute, there is an include to a setup.php at the bottom of the config file…
…
…
What if I set my $sslproxy before the include and…BINGO.
This is the crux of my rant here.
1) I have not ever seen a config file where things get ignored if they happen to be at the bottom of the file, which is a reasonable place to put site specific customizations.
2) Why on Earth is the config file calling anything? The config file should only ever be called by other stuff.
3) If you’ve chosen to implement a broken system with the above, at least put a comment in the code, something along the lines of, “#Add all site specific customizations above this line, else they may not be respected”. My site specific config file now has just such a comment.
Oh well.
