ianmjones

At the end of last week I created a brand new (free) FogBugz On Demand account, extracted my existing FogBugz MySQL database with mysqldump, and submitted it to Fog Creek to get it loaded up into my new account.

It took a few days before my new account was fully loaded, it seams Fog Creek have a little back log of uploads to do, obviously FogBugz On Demand has proven popular.

All is fine and dandy now, my support email is getting pulled into FogBugz On Demand directly from the POP3 account on my domain host (there was a little blip with the first couple of emails not being deleted from the POP3 server at first, but since then it’s worked flawlessly), and I can access my cases and get notifications with no problems.

However, there is one little gotcha, ScoutSubmit, the mechanism used by my applications (see RBScoutSubmit) for submitting crash data directly into FogBugz.

You see, my applications used to send their scoutSubmit data to my Mac OS X server sitting in my office at home, via a domain called support.imijsoft.com that I setup at my domain host to point back to my ADSL static IP address. This worked fine, occaisionally my ADSL would go down, so for an hour or two I might not get any crash data, but seeing as I can go weeks, if not months without a crash being reported, that wasn’t a big deal.

So, to make the switch seamless, I figured all I had to do was point support.imijsoft.com to the my new FogBugz On Demand domain via a CNAME alias, and I’d be home and dry.

How wrong could I be!

First, my old FogBugz server was at support.imijsoft.com/fogbugz/, and the new FogBugz On Demand server doesn’t have a /fogbugz/ path, oops!

Second, even once I had the new CNAME directive in place, when I accessed support.imijsoft.com FogBugz On Demand complained about there not being an account setup for support.imijsoft.com, oops again!

I contacted Fog Creek support to see if there was any way round the domain name not being a valid account issue, seems they are aware of it, and would love to be able to do something about it, and with a little work could probably get something in place, but there’s one big problem, SSL certificates. Currently, all FogBugz On Demand accounts are served up via HTTPS, as you would expect, and all are covered by the fogbugz.com certificate. Getting something in place that allowed other domain names to be used instead, with valid SSL certificates, that’s gonna be a nightmare, if it could be done.

The only option therefore would seem to be to change all my code to point to the new FogBugz On Demand URL, or switch back to using my own server.

I’m getting rid of my server soon (I’ll talk about that in a future post), so switching back is not an option.

I don’t want to change my code and release new versions of my applications to point to my new FogBugz On Demand account either, not only because I would then have to change and release new versions again if I decide FogBugz On Demand really isn’t for me (unlikely), but also because there are numerous versions of my applications already “out there” using the old support.imijsoft.com/fogbugz/scoutSubmit.php url.

So, the first (should that be second?) solution I came up with was to setup my support.imijsoft.com domain as a proper website on my domain host, and use a rewrite rule in a .htaccess file to proxy the requests through to FogBugz On Demand. This almost worked, I could get it working while accessing the website myself, but submitting data (using POST rather than GET) to scoutSubmit.php didn’t work, even with the rules taking into considderation the switch to ASP from PHP. I spent many hours last night on this, and then it struck me…

… I needed a proxy script, just like the one I’ve already developed for CaseDetective On Demand!

You see, CaseDetective On Demand is built with Flex, which runs in your web browser’s Flash engine plugin, which is very very serious about security. From Flash, you can’t grab data from any old domain, you have to have the authority to do so. To get data from a website without them putting a little file (crossdomain.xml) on their website that gives you permission, you have to use a proxy script. A proxy script is something non-Flash that you put on a site that you have control over and trust, which takes your request, forwards it onto the real destination url and then returns the results when they come back.

I built one of these little scripts for CaseDetective On Demand, so it wasn’t too hard to strip it down a little and make one for this job. You can download an example of the proxy script if you so wish.

The script works for both GET and POST methods of submitting data to scoutSubmit.php, I’ve placed this script in a fogbugz directory under my support.imijsoft.com root, with the root and fogbugz directory protected from prying eyes with a dummy index.html.

If you’re considdering switching from your own Linux or Mac OS X FogBugz install to the excellent FogBugz On Demand service, this script may just come in handy. You need to edit it before you use it to change the destination to your own FogBugz On Demand url, I think it’s pretty obvious as to where you do this.