I have a rails 3 app hosted on heroku which contains sensitive data which is why i want to implement SSL. The info I learned from google searching doesn't exactly match my use case as I want to SSL the entire site. I'd like your help understanding the following.
Is there a simple way to force all app requests to use SSL? I want the landing page to even have SSL as the landing page has a sign in form. It seems like it'd be a lot simpler to SSL everything than select SSL on a per page basis. That being said, do I need a gem for this?
Thank you
Look for a Rack middleware that accomplishes this.
https://github.com/tobmatth/rack-ssl-enforcer
I found this post today which is updated and looks like a good solution:
http://www.simonecarletti.com/blog/2011/05/configuring-rails-3-https-ssl/
I am using SSL Enforcer with Heroku and it works great. However, I had a lot of trouble setting up SSL on my dev machine (Ubuntu 11.04).
First, Webrick did not work with SSL, so I found a hack which worked for a while. But then I had a weird javascript and Google Visualization API problem with it.
Now I installed Thin (which was easy), but it is not working with SSL Enforcer.
If you have the time to install and configure Apache, SSL will work. But I don't think Heroku uses Apache, so that's not so good...
I can see why people don't want to figure out how to run SSL on their local machine...maybe it's not worth it if you have a staging or QA server that does run SSL.
Related
I'm a little confused with how deployment of an application works.
I've been looking up tutorials and numerous times it is suggested that it goes live with DigitalOcean, Heroku or something similar, but some are monthly payment services (albeit not a large amount).
I resell hosting to my clients when I build websites for them so I manage everything on my side. My question is: is there a way to deploy a Rails app to my own web hosting space rather than having to use a third-party service? Have I missed something in the documentation?
I'm certain that my hosting can support everything that's needed. If anyone could explain how or why not I'd really appreciate it :-)
You can set up the stack on your own server without problems. When you are using apache or nginx, the easiest might be to use passenger for serving your rails application.
You just need to make sure you have the right ruby version and bundler installed. Services like DO are just simpler to work with as they already do all the needed server setup and most of the configuration for you.
I would like to ask you a question about deploying a rails application onto a physical server.
Briefly, our dinosaur client doesn't want to store anything on the cloud hence he wants us to deploy everything onto his servers instead of heroku.
What should be the most efficient way to solve this problem? Won't he be able to reach the source code of our application?
That would be great if you can help me,
Thanks!
You might think on the variant when you keep only production database (and assets if client want) on the client's server and deploy your code to Heroku or whatever else.
Hi I've been learning rails for the past half year and have a few apps up on Heroku. So for me I thought deploying apps onto the world wide web was just as simple as heroku push. However, I just got my first internship doing Rails and one of my seniors is talking about Apache and Nginx and I'm not sure how they fit in the picture, since I thought apps consisted of only Rails + cloud app platform. I have looked it up but I still don't get how and where it affects my app life cycle. Can someone explain what/where/when of using web servers?
So you've got your Rails app, and as you know you've got controllers and actions and view and what not.
When a user in their browser goes to your app on Heroku, they type in the URL which points to the Heroku servers.
The Heroku servers are web servers that listen to your users that type in the URL and connect them to your Rails application. The rails application does its thing (gets a list of blog posts or whatever) and the server sends this information back to your user's browser.
You've been using a web server the whole time, just it was abstracted away from you and made super simple thanks to Heroku.
So the life cycle is somewhat like this:
Whilst you've been building your applications on your development machine you've probably come across the command rails server. This starts a program called WEBrick which is a web server, and listens on port 3000. You go to your app via http://localhost:3000.
WEBrick listens on port 3000 and responds to requests from users, such as the "hey give me a list of posts" command.
When you push your code into production (in your experience via heroku push) you're sending your code a provider who takes care of the production equivalent of rails server for you.
A production setup (which your senior developers are talking about) is a bit more complex than your local rails server setup on your development machine.
In production you have your Rails server (often things like Unicorn, Passenger) which takes the place of WEBrick.
In a lot of production setups, another server, such as Apache or nginx is also used, and is the server that the user connects to when they go to your application.
This server exists often as a bit of a router to work out how different types of requests should be handled. For instance, requests to static files (css, images, javascript etc) that are storted on the server might just be processed directly by Apache or nginx, since it does a fantastic (and fast) job of sending static assets back to the client.
Other requests, such as "get me a list of all blog posts" get passed onto the Rails server (Unicorn, Passenger etc) who in turn do the required work and send the response to Apache/nginx, who send it back to the client.
Heroku does all this for you in a nice easy to use package, but it sounds like the place your working at manages this themselves, rather than using Heroku. They've setup their own bunch of web servers, and will have their own way doing an equivalent of heroku push which will send the code to the servers, and make sure they're up and running ready to respond to user requests.
Hope that helps!
Web Pages need a Web Server to make them available on the Internet.
So a site that is all static content (all just .html pages) just needs a web server and that's where Apace, nginx, etc come in. They are web servers.
When you use frameworks like rails, an additional component is added, an application server. This pre-processes the pages using the rails framework and then (still) uses the above mentioned web server to make the final pages (which are .html of course) available to the end users through their browser.
Passenger Phusion is an application server that, with rails will help manage and automate the deployment of code.
Heroku is a cloud service, meaning they take care of hardware and software allowing you to seamlessly publish you application without worrying about what is going on behind the scene. So the only thing you have to do is push your code to their Git and voila.
On the other hand, Rails can also be deployed on a system built by you completely from scratch, and you will be the responsible not only for the app development but also for the server maintenance and choice of the hardware and/or software. You could then choose between several application servers capable of running rails such as ngix.
Hope that helps.
I am part of a team that manages a public facing cloud platform at my company. We have a large user base running VM's that face the internet. I would like to run an automated scan of our address space and see if anyone is running a Rails app so I can notify them to upgrade their version of Rails to avoid a critical security vulnerability that came out this week.
I've noticed that in some Apache deployments, there is a Passenger Header that is useful:
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.0.3
However, this is not reliable. I'm wondering if there is a reliable way to detect Rails running behind a web server either with response headers or some kind of a GET / POST that can be definitive. Thanks!
Every Rails site has:
meta content="authenticity_token" name="csrf-param'
Or could have a submit button where the name="commit"
At least that's what I have consistently seen.
Header responses are not reliable, here are three from various Rails sites:
Server:Apache/2.2.14 (Ubuntu)
Server:nginx
Server: thin 1.4.1 codename Chromeo
You know nginx and Thin are popular in the Rails community, but that's not conclusive enough to say there is Rails behind it. You would need to run a script that scrapes the site and looks for the meta-tag above. BeautifulSoup is a pretty good if your script is going to be in Python. Mechanize gem is great if you are going with Ruby.
Most rails apps have a submit button where the name="commit"
A Rails app could be running on lots of different ports, depending on the configuration allowed. That, plus the fact that the app might not respond in a way you can recognize, seems like a "sub-optimal" way to find out.
Instead, if you own the hosting, you own the drives and the systems supporting the apps. Why not run a grep across the systems, looking for strings matching Rails.
Or search for some of the standard Rails files; Use find, or locate if you have it running.
Another default setting of Rails that is commonly left untouched is the name of the main /assets/application-<hex hash>.{css,js} files.
I don't thing that a single reliable way of detecting Rails exists, but by using a combination of the authenticity_token, the default assets names and the HTTP headers, you should be able do identify the vast majority of the Rails apps.
The Wappalyzer script uses these three criteria and considers that the co-occurrence of two indicates a Rails app.
Wappalyzer is a good option, and (shameless plug) have you looked at Spotkick? We're in private beta now, but it's a distributed engine for running open source apps, so you could run Wappalyzer across all of your sites to see what's probably running rails.
I do this for banklook.com - I run over about 6800 banks to dig up details about security risks.
Let me know if you want more details or information.
I have a Heroku e-commerce site I'm building, and have the Piggyback ssl installed by following the Heroku Piggyback tutorial. I'm planning to upgrade to SNI or host-name SSL after sales come in to support it.
I can't find any tutorials or examples of best way to handle where the SSL is integrated for the processing (just checkout I believe).
Are there any tutorials, or process workflows to setup a controller and view to abstract for handling the actual checkout experience, and redirecting confirmation or failure when using the piggyback ssl on Heroku? And keep in mind upgrading the system in the future for upgraded SSL (using SNI or Hostname SSL)?
The best explanation I found was from this question, but it wasn't a walk-through, tutorial, or real explanation explain how to solve the url creation for links on the Piggybacked url (appname.heroku.com). I was looking for more detail in implementation.
Piggyback SSL is identical to regular SSL, except for the fact that only heroku.com or herokuapp.com domains (dependant on your stack) are secured by the cert that you have setup for you.
In order to run a page securely, just run it over HTTPS.
However, with Rails you have the option of using the SSL_requirement plugin from DHH which lets you tell rails which controller actions MUST be handled securely, and which are fair game for HTTP. By using SSL requirement you can forget in your routing about SSL as SSL_requirement will take care of it for you.