Closed groovecoder closed 10 years ago
Any reason we shouldn't force SSL for all access?
I'm not opposed to forcing SSL for everything, in fact I have https://codesy.metamize.net/ doing that right now with a self-signed SSL cert (so you'll have to add the exception to your browser if you want to play around). It's running in an LXC container on a rackspace cloud server right now, but we can copy the container pretty much anywhere. If we want to put the current setup in production on https://codesy.io we just need to buy a cert for codesy.io, reconfigure nginx to use it, and update the DNS to point to that server. I'm fine with hosting it on my personal server, but I have several other things running on it, so we may want to set up a dedicated box. I can just add one and file expense reports or whatever, or we could set up a codesy account on rackspace, digitalocean, aws, etc, and bill directly to the codesy account, and make sure that we all have the credentials, etc, which is probably the "right" solution.
We can use SSL with heroku right now (https://codesy.herokuapp.com/) and we could use ssl on heroku for production on a subdomain of codesy.io, for example https://api.codesy.io, but not for the root domain (https://codesy.io). See https://devcenter.heroku.com/articles/custom-domains#root-domain for more details.
For the add-on and extension to work properly, we'll need to get the certs signed. :/
On Mon, Dec 2, 2013 at 1:35 AM, Josh Mize notifications@github.com wrote:
I'm not opposed to forcing SSL for everything, in fact I have https://codesy.metamize.net/ doing that right now with a self-signed SSL cert (so you'll have to add the exception to your browser if you want to play around). It's running in an LXC container on a rackspace cloud server right now, but we can copy the container pretty much anywhere. If we want to put the current setup in production on https://codesy.io we just need to buy a cert for codesy.io, reconfigure nginx to use it, and update the DNS to point to that server. I'm fine with hosting it on my personal server, but I have several other things running on it, so we may want to set up a dedicated box. I can just add one and file expense reports or whatever, or we could set up a codesy account on rackspace, digitalocean, aws, etc, and bill directly to the codesy account, and make sure that we all have the credentials, etc, which is probably the "rig ht" solution.
We can use SSL with heroku right now (https://codesy.herokuapp.com/) and we could use ssl on heroku for production on a subdomain of codesy.io, for example https://api.codesy.io, but not for the root domain ( https://codesy.io). See https://devcenter.heroku.com/articles/custom-domains#root-domain for more details.
— Reply to this email directly or view it on GitHubhttps://github.com/codesy/patronage/issues/21#issuecomment-29599221 .
Yea, self-signing has already proven problematic as I've been working on this. Firefox seems to work ok, but Chrome seems to require some voodoo on OSX.
Uplifting info from email thread:
I like @jgmize idea to use https://codesy.herokuapp.com/ for dev, https://codesy-stage.herokuapp.com/ for stage, and https://api.codesy.io for production so we only have to buy 1 certificate.
But we would need to change our Github application to OAuth back to those domains.
Submitted CSR for api.codesy.io to Comodo SSL ...
Just waiting on them now.
We got the cert files back from Comodo to our founders@codesy.io inbox. We should set up a new api.codesy.io Heroku app and add an SSL end-point to it.
https://api.codesy.io is now live.
Firefox add-on error:
Do we have a production environment for the main codesy.io domain yet? We need to get an SSL certificate so content script requests from
https://github.com
... are not blocked by mixed content issues.