A frequent problem I have is using CSS files which include http:// linked background images, which will pass through every test with flying colors and then trigger prominent mixed-content security warnings in a browser I very seldom use. Slap this code in your initializers directory and you never have to worry about it again.
Just write your stylesheet_link_tag as normal, and then include :cache => request.ssl? ? "foo-secure" : "foo-standard"
Bonus: the included code also minimizes CSS and JS files in production, saving you page load time.
The minimizing is good, but doesn't using a path like //example.com/my-image.jpg instead of http://example.com/my-image.jpg fix the issue with http/https?
That works if you can enforce that 100% of the time, against all CSS loaded by your site. The first time you forget it in e.g. a lightbox script you add to get used on a landing page whose implementation you didn't even glance at, your registration page will break. This has cost me thousands of dollars before, so I enforce assumptions like "there are no http:// urls in my CSS files" in code.
I usually just use whatever is the most robust, stable open source choice for Rails app. Sphinx for search, etc. and Apache for the web server. Doing SSL is well documented and pretty much everything is possible and documented and supported by webmin too. I have a virtual host sending all non-ssl requests to ssl.
It doesn't have to be Ruby, especially if I won't be programming for it anyway.
This is an additional (draft status) header that tells the user agent to always (or up to X seconds in the future) use HTTPS for that site and it seems, to disallow any connections using bad certificates.
Currently only Chrome and latest dev version of Firefox seem to support it. Chrome apparently has a pre-loaded list of always-https domains, like www.paypal.com -- who are also the people behind this draft proposal.
The one problem nobody talks about is that browsers won't cache content served over ssl, which means your website will be a lot slower to your users. That will directly costs you money.
Firefox does cache content - I just ran Firebug to confirm. I can only assume from how fast my site works in other browsers that the same applies to them. What browsers are you referring to?
Thank you, your comment reminded me of why this is Severity: Critical. Here's where Thomas and I live in different worlds: I hear "open proxy" and I think "a malicious user can use your server to attack other services on the Internet or download kiddie porn.". Thomas hears "open proxy" and starts to see visions of a host possibly within the firewall which can be used to make arbitrary HTTP requests against servers within the firewall, which let's you target the weak underbellies of e.g. intranet applications which have no security because all users are presumed to be employees and where compromise can do interesting things like e.g. read out all your source code through Trac, initiate wire transfers through the accounts payable application, etc.
Sev: biblical. You're coughing up the lights-out management consoles on servers and storage appliances with them. I'm sure there's all sorts of funny business to be perpetrated through them with admin and account management applications. But I wouldn't know, because you're usually 5 minutes from command execution on the server once you find one.
Hmm, probably. Doesn't sound like a bad idea. Still, if the proxied request takes a long time, you might be locking out other requests from hitting the real app.
Would I be right in thinking that if I was serving my app using an evented web server (nginx) this would not be such a problem? Or would it still be tying up a passenger instance anyway? If my request hits the router and then goes straight to a seperate rack app, does this still require a full weight passenger process and one copy of my full app stack in memory (albeit shared memory?)
In the spirit of creating wealth through exchange:
https://gist.github.com/721114
A frequent problem I have is using CSS files which include http:// linked background images, which will pass through every test with flying colors and then trigger prominent mixed-content security warnings in a browser I very seldom use. Slap this code in your initializers directory and you never have to worry about it again.
Just write your stylesheet_link_tag as normal, and then include :cache => request.ssl? ? "foo-secure" : "foo-standard"
Bonus: the included code also minimizes CSS and JS files in production, saving you page load time.