I'm using Puma (version 3.11.0) as the web server for a Rails application (Rails version 5.1.4). I need the whole application to be SSL encrypted, but I need one particular route to also have the SSL "verify_mode" set to peer. In Apache, I would normally use a "Location" or "LocationMatch" block to configure the SSL options differently from the rest of the site.
How can I do the same thing with Puma?
I totally agree with #user3309314.
Exposing Puma to the internet directly (or exposing any application server, for that matter), isn't a great idea.
Web servers (unlike application servers) are designed to be in the front, protecting application servers from the cruel world...
...and along the way, they should be the ones to handle SSL/TLS (along with DoS attacks and other annoying concerns).
So use nginx or apache to forward requests to your Ruby application(s) and if you need a special TLS/SSL rule for a specific path, do that with nginx or apache.
Puma doesn't (and IMHO shouldn't) support the feature you're asking about.
EDIT (some of the information given in the comments + explanations)
It's best to think of application servers as a "bridge" between the host machine's routing layer (nginx/apache) and the applications.
It's the host routing layer (nginx/apache) that filters and routes certain host names and paths to certain applications (or the same application with different headers / variables / requirements).
The application server's job is to simply "bridge" between the host routing layer and the actual application, translating between the different data formats (HTTP data to Ruby objects and back).
In order to support the feature you're asking about, the application server should perform the same functions as the host routing layer (routing the correct host name / path to the correct application with the correct changes)
This would violate any "separation of concerns" as well as add redundancy to the system, inflicting a performance penalty (not to mention the larger code base that duplicates the same task in different modules).
This is the reason why, IMHO, these features should not get coded into Ruby application servers.
It's unlikely that Puma supports this.
But you can configure Nginx or Apache as a reverse proxy, so requests get forwarded to the Puma application server, and you can configure SSL options as you need.
Related
I want to add a new project beside of my current rails app without starting a new server for that.
I think it is impossible to have two rails app on one port but my boss want it.
Is it possible at all?
Yes it's possible if you configure a web server (nginx, etc) as a reverse proxy to listen on the port you want, and have it forward traffic to the correct app based on subdomain.
Yes and no. You can't run two web servers, e.g. Puma, on the same port. That won't work. But you can run one web server to serve two Rails apps. Incoming requests are routed based on either their subdomain (app1.example.com) or their path (example.com/app1).
A common setup is to use Apache/nginx as the web server in combination with Passenger as the application server. This question ask a similar question and points to Passenger's documentation on how to serve apps from subdomains: How to deploy multiple rails app on a single IP (Apache + Passenger)?
The configuration depends heavily on your setup, so I can't give you a more detailed answer. But searching for "multiple apps" and the combination of your web and application server should yield enough results and tutorials for you to solve your problem.
With the upcoming SSL migration at Facebook on 1 October, all apps will have to support connections over HTTPS and for that you'll need an SSL certificate.
Is there a run-down anywhere of how a person should patch an app?
Will you have to use Apache and Passenger, xginx or other server?
Are there any free trusted certificates?
Is there a run-down anywhere of how a person should patch an app?
Not really. Why? Because it all depends on what version of rails you are running.
For Rails 2.x, I've read/heard of techniques including:
ModRewrite - use the webserver's ability to detect and rewrite HTTP to HTTPS. This technique is more general and could apply to a whole host of technologies, not just rails (python, java or even .net).
Use ssl_requirement gem - this allows you to declaratively add instructions in your controllers to redirect to https if the protocol is http (https://github.com/retr0h/ssl_requirement). Although simple, your ruby app will have to handle the request, and I'm not sure how quick ssl_requirement is.
Use rack middleware (rack-ssl, rack-ssl-enforcer gem) - this patches the request handling of rails, so that the redirect is handled well before it hits any controller. This is configureable too (you can match based on path etc) and is probably better than option 2.
For Rails 3.1, it's backed into the framework. You just need to do this:
# config/application.rb
module MyApp
class Application < Rails::Application
config.force_ssl = true
end
end
Will you have to use Apache and Passenger?
Not necessarily. There are other options like NGinx and Passenger. But in general, yes you will probably need a proper web server sitting in front, handling the SSL portion of the request.
Typically, a web server is required to sit in front of your app. It needs to be configured to handle SSL traffic, and direct the requests to your app (http and https). Here you can use Apache or NGinx.
Passenger sits as a "plugin" in Apache/NGinx to handle requests through to your application. At this point, SSL isn't usually a concern (ie. the request is now unencrypted.). What your app has to then do, is handle the request. Here's where you detect if the protocol is http or https and instruct the browser to redirect if necessary.
Are there any free trusted certificates?
No. Trusted certs are usually signed by a Certificate Authority. These guys typically have to check that your domain and the company or individual that holds the domain are genuine and real. To do that, you pay money. There are plenty of providers out there that can issue you an SSL cert for around $100 USD. Some more, some less.
Certs are typically locked to a domain. And you pay more for wildcard domain matches (e.g. *.myapp.com). If you're after a cert for development, you can generate a self signed certificate.
I've written an article showing you how to get HTTPS going on your local dev instance. Many of the steps are also common for production. The article shows you how to set it up for POW and NGinx, but setting up for Apache and Passenger isn't too dissimilar. The Apache config is different. But Passenger install and setup should be just the same as a http environment. Just need to make sure the secure virtual host in your Apache config points to your application.
I have different websites/applications built with rails, which has different domain names. The thing is I want to serve them from a server with Nginx/passenger. I tried some techniques, but I cannot make them work, basically, I have very few information about this.
So, I can serve different websites/applications on different ports. But how can I make people to see application "AAA" if they are coming from aaa.com and see application "BBB" if they are coming from bbb.com?
Phusion Passenger's documentation has a passage on this here, section 3.2: http://www.modrails.com/documentation/Users%20guide%20Nginx.html
Basically, you can set up virtual hosts that point to different applications on the same web server/app server pair.
You can also do rewrites or forwarding purely through nginx configuration, if the above doesn't work.
I would like to have multiple RoR applications that can communicate with each other (databases, method calls, ...).
Example of what I would like:
a main application running on a URL http:// www.< application_name >.com
a sub-application 1 running on a URL http:// www.< application1_name >.< application_name >.com
a sub-application 2 running on a URL http:// www.< application2_name >.< application_name >.com
each with own databases.
How can I configure my applications? Where can I find a tutorial for my needs?
No Problem. In your case you will have 3 distinct Rails applications. You will setup your Webserver to send requests based on host accessed to one of the three applications. This is standard web server configuration. You'll need to read Apache or Nginx configuration on how to route request to the right rails application.
EDIT:
http://articles.slicehost.com/2009/3/11/ubuntu-intrepid-nginx-rails-and-mongrels
Not sure what you are going to use as your Web Server (Apache or Nginx or something else) or what you are going use as your application container (mongrel/passenger/thin etc) but this article above should help.
You might take a look at the eco_apps gem - https://github.com/idapted/eco_apps. I heard the developers give a talk about it at Rails Conf '10. Fascinating stuff, though I haven't had a chance to use it yet.
This is a newbie question around nginx and thin in the rails environment. In reading/learning on rails I frequently hear about nginx and thin being a great combination for a rails site. In reading the descriptions of each, they both describe themselves as web servers, so I'm a little confused at what the combination brings to the table. If anyone could briefly describe what they are and how they complement each other I would be greatly appreciative.
Thanks!
A typical small application deployment will have Nginx(or Apache) and a handful of Thin(or Mongrel, Unicorn, etc) servers running all on one machine.
Nginx receives every request. It then serves and static files directly (css, js, images, cached stuff). If the request requires processing it then hands the request off to a rails process (Thin).
This way your (relatively) slow application servers are freed up from serving static files, and your web server is providing a sort of load balancing.
The benefit of Nginx/Thin over something like Apache/Mongrel is that Nginx/Thin can communicate directly via a unix socket, removing the overhead of communicating via the tcp/ip stack.
Thin is an application server while Nginx is a web server.
From http://www.javaworld.com/javaqa/2002-08/01-qa-0823-appvswebserver.html
The application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).
Speaking out of ignorance (I've never used Thin), it is quite normal to mix nginx and an application server together, using nginx to serve up static content and act as a reverse proxy for the application server.
This makes it easy to blend ludicrously fast static content serving with the application server of choice (which varies between programming languages), all coming from the same address:port.