How do you stage a Facebook canvas app?
I've taken over the hosting responsibilities for some servers hosting (among other things) Facebook canvas apps. The developer used to "deploy" his app to the server by simply uploading the PHP files to the one production server.
Since taking over the server admin, I've of course switched from a single web server to multiple redundant servers, and instead of deploying directly to a production server I've instructed this developer to deploy to a new server instance created specifically to serve as a staging server.
Now he's complaining that he can't test his Facebook canvas app on the staging server because it doesn't have an SSL certificate, and browsers won't allow self-signed SSL certificates. (The issue isn't just him QAing it, but he needs to have the client QA it as well.) As it turns out, Facebook canvas apps are basically just webpages served in an iframe.
The app needs to be fully-functional (so we can show it off to the client), and also be running in the Facebook environment. When the app is "approved", we need to be able to swap the Facebook app configuration to serve from the production servers instead of the staging server so the URL doesn't change. Preferably:
1) the staging server should remain identical to the live servers
2) we don't need to make a brand new domain/SSL cert just for this one basic task
The first issue can be solved by making a Amazon load balancer that will exist to just serve up the staging server, and attaching the cert/whatever configuration to the load balancer instead of the server directly. The second issue... I'm not sure there's any way around.
So what's the industry-standard way to stage Facebook apps?
Why do you need an entirely different domain? I'm no SSL expert, but couldn't you use a subdomain, or if that doesn't work, just make staging and production different folders on the same server, with ACL's to prevent real users from accessing staging?
Well, I was hoping to avoid the cost of a new SSL cert for a subdomain. (It's not a wildcard cert, unfortunately, so we have to pay for each subdomain.) Also I'm not sure I can get that set up by Tuesday, which is when we need to show this to the client.
or if that doesn't work, just make staging and production different folders on the same server, with ACL's to prevent real users from accessing staging?
There isn't a "the" server, it's a cloud environment. That's exactly the problem-- this guy was used to idiot IT admins who had a single web server and just let him deploy directly to it. The entire exercise here is to stop that from happening.
So the folder thing is a non-issue. You can't have AWS switch a load-balancer based on what folder is in the URL.
Sorry, you never told me anything about enterprisey head-in-the-cloud things; you just said there were multiple load-balanced servers!
So the issue now is the staging server needs an SSL cert, and the SSL cert needs a subdomain, and that means it'll take about 48 hours to get a subdomain and another 6-12 hours to get a SSL cert and there's no way this can be ready in time to demo to the clients on Wednesday.
So I have to let this shitty dev do his release "process" one last shitty time and now I feel like shit.
Why does a subdomain take so long to get?
As regards cost for SSL certs, ever think about moving to a free provider? such as StartSSL? They're fairly well supported by most browsers. even most of the obscure browser (such as those in the TV domain) i use tend to accept them.
Because it's a corporation and I don't control the DNS.
As regards cost for SSL certs, ever think about moving to a free provider? such as StartSSL?
I agree - Use a free StartSSL certificate for the staging server.
Stack overflow is having answer for you.