I am developing my first rails 6 app but when I try to serve it in development environment behind my nginx server, I find this message
I tried adding the configuration mentioned in the error in config/environments/development.rb and in config/application.rb but it didn't work.
I am using rails 6.0.0, ruby 2.6.5, nginx 1.10.3
If I go to http://localhost:3000 (the puma URL directly) it works fine. But I want to know why I am getting this error.
It was an issue on Rails side.
Upgrade to 6.0.4.4 or 6.1.4.4 like you can read in their blog post.
Host Authorization is added because of DNS rebinding attacks here are more details about and also link to more detailed explanation.
Introduce ActionDispatch::HostAuthorization Host Authorization is a
new middleware that guards against DNS rebinding attacks by explicitly
permitting the hosts a request can be sent to. More information about
the attack itself is available in this Medium post and in Daniel
Miessler’s DNS Rebinding attack explained. By default it’s set for all
Rails 6 applications and allows in development the following hosts
IPAddr.new(“0.0.0.0/0”), IPAddr.new(“::/0”), “localhost”] it supports
arrays of RegExp, Proc, IPAddr and String or a single String in the
configuration. What this means is that with Rails 6, we will need to
explicitly set our domains in the environments configuration files.
More information is available at the HostAuthoriation code and
HostAuthorization tests.
Related
I was wondering if there was a way to use the Puma server (Rails default) JUST on the new Rails 5.1 system tests?
Right now on all our projects we use tiny_tds, but I was trying to experiment with 5.1 system tests with Capybara/Selenium but it fails of course because I do not have Puma installed/running.
I took a look through the documentation and didn't see anything about declaring what type of server you want to use. Were connecting to a SQL Server database so I don't know if Puma is able to do that (And that's probably why were using tiny_tds in the first place).
You're confusing database adapters and rack web servers which are very different things.
Puma (like Webrick, Thin, Unicorn etc) is a general purpose Rack web server. It sits and waits for incoming requests from vistors and dispatches them to an application (like a Rails app) by calling it with a hash containing the environment and request. The application returns an array containing the response. The server sends it back to the visitor.
tiny_tds on the other hand is a database adapter. Its used to connect the application to the database. The web server is almost completly oblivious to how the application creates a response from the request. This includes whatever databases are used.
In Rails 5 most servers don't require configuration. You just add the gem to the gemfile and run bundle install and they plug themselves in. There in no seperate installation step.
That was not the case earlier which is why Webrick - a server with the only real merit being that it does not require configuration was the default. It is now Puma which unlike Webrick is suited for production.
Using different servers in different environments is not a good idea since it violates the idea of dev/prod parity. Your dev & test environment should be as close as possible to what you are deploying to so that you can catch bugs before they end up in production. This means you should be running the same server, same database etc.
Running a seperate test server for different parts of your test suite sounds like a true fools errand - if its even possible without hacking the framework to bits.
For SQL Server there is activerecord-sqlserver-adapter which can use tiny_tds as a backend.
I just upgraded my Rails app from 4.1.3 to 4.2.4. I had previously edited my development server's host file so that my.domain pointed to localhost and had been using this to work on my app. However, now that I've upgraded to rails 4.2.4, my.domain:3000 doesn't connect; only localhost:3000 does.
I can't remember if I originally configured anything else that would have been affected by the upgrade but I don't think I did. There's nothing in the development.log that would give any hints (makes sense given that the browser says it's not even connecting).
In the event that it matters, I'm using gem 'foreman', '~> 0.78.0' on my dev server.
I know I'm not giving a lot to work with but does anyone have any ideas as to what might be going on here?
This probably has to do with Rails 4.2 no longer binding to the public interface. I'm not sure if your dev server is local or not. If it is, you will probably need to adjust your hosts entry to 127.0.0.1 instead of 0.0.0.0. If not, you will probably need to allow Rails to use the public interface. There is a bug report for this issue, which contains some possible workarounds.
Due to a change in Rack, rails server now listens on localhost instead of 0.0.0.0 by default. Refer 4.2 release notes Start your server with :
rails server -b 0.0.0.0
to restore old behaviour
I'm very surprised to find such little documentation on this topic which quite many developers must have faced before me.
We're changing our app to 100% HTTPS/SSL (as partial SSL doesn't make sense).
That's cool but before that, we need to migrate to it, hence to test it. Of course I found some basic information (here and here).
As I'd like my local environment to be as close as possible to the other ones in order to avoid unexpected errors, those solutions are not satisfying to me : they are ok for short time testing a feature, not more.
Here are the problems/questions I have:
Can I get a valid certificate for my local machine, to avoid the ugly warning step I can't even accept definitively on chrome?
Booting server with thin (thin start --ssl --ssl-verify --ssl-key-file server.key --ssl-cert-file server.crt), can I get same log messages as from rails server?
Can't I keep using rails server as a booting command (except by writing an dirty ALIAS ...)
Summary question is can I make a config so that it is transparent for anybody to run the instance of our app locally in https?
I mean, absolutely everything's done in rails to make development easy, and production robust, but here, there would be such a lack of good tools? I hardly can believe it ... or let's do it now!
Thanks for support! I'm using rails 3.2 with ruby 1.9.
Can I get a valid certificate for my local machine, to avoid the ugly
warning step I can't even accept definitively on chrome?
This depends if you're using the actual certificate for your domain (eg. example.com), or generating one just for development. If you are using the actual certificate from production, you could simply edit your hosts file to have example.com resolve to localhost. Then visiting https://example.com should load your Rails app.
You'll probably also need to include this in your application.rb:
config.force_ssl = true
If you're generating your own certificate you'll need to go through the motions of creating a private Certificate Authority to avoid the SSL warning in Chrome. This is a lot more work and probably not worth it.
Booting server with thin (thin start --ssl --ssl-verify --ssl-key-file
server.key --ssl-cert-file server.crt), can I get same log messages as
from rails server?
You should be able to tail -f log/development.log from the root of your Rails app.
Can't I keep using rails server as a booting command (except by
writing an dirty ALIAS ...)
This one is trickier as the server that runs when using rails s is WebBrick. You could try what's listed in this post here: Configuring WEBrick to use SSL in Rails 4
As an aside the typical setup for a Rails app is to proxy it behind say an SSL terminated nginx server. This way your Rails app doesn't need to know anything about SSL, as well as giving you a number of other benefits like being able to serve assets from nginx, load-balancing, virtual hosts etc.
If you're interested in setting up an environment that is identical to production I'd look into Vagrant.
I'm hearing that SPDY is where things are likely headed, and I'd like to try to use it with a Rails site I'm running. I haven't been able to find any tutorials however, and the one gem I found doesn't seem to work (everyone is reporting the same error on it across all browsers).
Is it currently possible to implement SPDY on Heroku with a Rails app?
No, there is no way to get SPDY on Heroku today, although I do hope that will change in the future. Heroku has their own HTTP "routing fabric" which is fronted by nginx frontends. The nginx team is working on a SPDY module, but there is no hard date for its release yet. In addition, Heroku would need to install it on their frontends, etc -- in other words, it would require some careful coordination.
If you are interested in testing SPDY with Rails, I would recommend checking out mod_spdy for Apache. You should be able to use Passenger in conjunction with mod_spdy, although that would have to run outside of Heroku for now.
Try setting up CloudFlare an SPDY CDN/proxy service
You can set up a reverse proxy in front of your Heroku app.
One way to do it is using Dockhero addon.
Here's an example with SPDY / HTTP/2 / QUIC support to your Rails app hosted with Heroku - https://github.com/dockhero/quic-protocol-demo
Dockhero add-on is in Private Alpha as of September 2016, try it for free by signing up at https://dockhero.io/
I've got the following problem. I want to explicitly tell rails the port it is running on, so that the _url helper will use that port instead of the autodiscovered port.
The underlying problem is, that I have thin serving my rails app and apache serving static content. This works fine as long as the website is accessed on port 80 (apache) but not when accessed on the port thin is running on. (Which is the port that get's auto discovered.)
Rails is supposed to create relative links, which do not include the fully qualified domain name, see example here, I quote :
link_to "Profile", profile_path(#profile)
# => Profile;
the *_url shortcuts, on the other hand, are using the full path, which is bad when you're behind a reverse proxy (that's apache in your case).
Have you tried using only *_path for links, and *_url for redirects, as, in the case of a redirect, apache should rewrite the url to match its port (assuming you're using the ProxyPass and ProxyPassReverse directives at Apache level) ?
If you use url_for, you can force it to be relative by setting the :only_path to true.
If your apache configuration is not based on ProxyPass, could you please copy/paste the interesting part so I can fix this answer ?
Thanks in advance.
Because Ruby on Rails uses its own server, users visiting your website (and subsequently your Ruby on Rails application) will need to be redirected to the appropriate port.
To change the port of Ruby on Rails server you should start the server with the -p option:
ruby s -p <port-number>