I am using a CMS called Radiant (version 0.9.1), Rails 2.3.18 and Ruby 1.8.7. I have to make the routes in this gem use the 'https'. I need to do it in such a way that I won't edit the gem source files itself, but rather override the gem's routes in the extension. How do I do this?
The configuration of the server really depends on what your server stack looks like
To configure your rails application to use SSL you need to force ssl
In your config/environments/production.rb:
config.force_ssl = true
To test ssl locally I would suggest trying thin as a webserver (also put config.force_ssl in development.rb to test this )
Add:
gem 'thin'
To your gemfile and start a thin ssl server:
$ thin start --ssl -p 3000
EDIT Rails 2 :
For Rails 2 this should work:
lib/force_ssl.rb
class ForceSSL
def initialize(app)
#app = app
end
def call(env)
if env['HTTPS'] == 'on' || env['HTTP_X_FORWARDED_PROTO'] == 'https'
#app.call(env)
else
req = Rack::Request.new(env)
[301, { "Location" => req.url.gsub(/^http:/, "https:") }, []]
end
end
end
config/production.rb
config.middleware.use "ForceSSL"
config/application.rb
require File.expand_path('../../lib/force_ssl.rb', __FILE__)
source: Force SSL using ssl_requirement in Rails 2 app
I am trying to run faye automatically using gem daemon_controller.
My Class
require "daemon_controller"
class FayeDaemon
def initialize
#controller = DaemonController.new(
:identifier => 'Faye server',
:start_command => "rackup faye.ru -s thin -E production",
:ping_command => [:tcp , 'localhost', 9292],
:log_file => 'log/faye.log',
:pid_file => 'tmp/pids/faye.pid',
:start_timeout => 5
)
end
def start
#controller.start
end
end
Function I use as before_filter in ApplicationController
def start_faye
fayes = FayeDaemon.new
fayes.start
end
as a result faye doesn't run with error
DaemonController::StartTimeout (Daemon 'Faye server' didn't daemonize in time.)
when fayes.start is called.
what i did wrong?
I highly recommend you to use foreman instead of deamon_controller, you can find good introduction here. Just install gem, create 'Procfile' in your rails root directory. and create two jobs, one for server and other for Faye, it could look like this:
web: bundle exec rails server webrick -b 127.0.0.1 -p 3000 -e development
faye: bundle exec rackup faye.ru -s thin -E production
and start foreman with
foreman start
I want to set the default port when I do
rails s
to 3010, instead of having to say:
rails s -p 3010
...every time. Any ideas?
You can override the Port by adding the following code to config/boot.rb
require 'rails/commands/server'
module Rails
class Server
alias :default_options_alias :default_options
def default_options
default_options_alias.merge!(:Port => 3010)
end
end
end
I have been running a rails 2.3 app with a rackup config.ru file to load some grape API middleware.
I recently have a need to run a resque server.
My config.ru is set up like this.
require File.dirname(__FILE__) + '/config/environment'
my_app = Rack::Builder.new do
use Rails::Rack::LogTailer #optional
use Rails::Rack::Static # optional
run ActionController::Dispatcher.new
end
Resque::Server.class_eval do
use Rack::Auth::Basic do |user, password|
begin
if user == "admin" and password == "bandana"
true
else
false
end
end
end
end
run Rack::URLMap.new([
"/" => my_app,
"/resque" => Resque::Server.new
])
run Rack::Cascade.new([
GrapeAPI_entry_1,
GrapeAPI_entry_2,
my_app
])
This doesn't give me the desired effect and I don't know why.
I actually found the answer. It turned out that redis was not running, and yes, you can use cascade with map
My final config.ru looks like this.
re File.dirname(__FILE__) + '/config/environment'
require 'resque/server'
my_app = Rack::Builder.new do
use Rails::Rack::LogTailer #optional
use Rails::Rack::Static # optional
run ActionController::Dispatcher.new
end
Resque::Server.class_eval do
use Rack::Auth::Basic do |user, password|
begin
if user == "admin" and password == "bandana"
true
else
false
end
end
end
end
app = Rack::Builder.new {
use Rails::Rack::Static
map "/resque" do
run Resque::Server
end
map "/" do
run my_app
end
}.to_app
run Rack::Cascade.new([
Grape_API_1,
Grape_API_2,
my_app
])
I recently added similar access to resque on one of my rails servers. It works great -- here is how I did it:
# This file is used by Rack-based servers to start the application.
require ::File.expand_path('../config/environment', __FILE__)
require 'resque/server'
run Rack::URLMap.new \
"/" => MyApp::Application,
"/resque" => Resque::Server.new
My app is based on rails 3.2, however. I'm not sure what the difference is in the rack version you're running.
Are you requiring the resque server code?
Does anyone know of a way to run the ruby debugger and SSL at the same time with Thin?
I've been using Thin successfully with Rails 3.0.10.
I start it using rails server --debugger, and I can debug my code.
Recently, I have also needed to add SSL support to my application, and I'd like to be able to test it locally with a self-signed certificate.
Unfortunately, I have not found a way to start Thin with SSL support when using rails server.
I can successfully start Thin with SSL support by using:
thin start --ssl --ssl-verify --ssl-key-file ssllocal/server.key
--ssl-cert-file ssllocal/server.crt
However, I have not found a way to activate the debugger using thin start.
So it seems like I have the choice of running the debugger (rails server) or SSL (thin start), but not both.
It seems possible to get Webrick to run SSL using rails server by modifying the rails/script file (see here). I experimented with this approach, but I have not had success. Here's one of the attempts:
#!/usr/bin/env ruby
# This command will automatically be run when you run "rails" with Rails 3
# gems installed from the root of your application.
APP_PATH = File.expand_path('../../config/application', __FILE__)
require File.expand_path('../../config/boot', __FILE__)
# THIS IS NEW:
require "rails/commands/server"
require 'rack'
require 'thin'
module Rails
class Server
def default_options
super.merge({
:Port => 3000,
:environment => (ENV['RAILS_ENV'] || "development").dup,
:daemonize => false,
:debugger => false,
:pid => File.expand_path("tmp/pids/server.pid"),
:config => File.expand_path("config.ru"),
:SSLEnable => true
:ssl => true,
"ssl-verify" => true,
"ssl-key-file" => File.expand_path("ssllocal/server.key"),
"ssl-cert-file" => File.expand_path("ssllocal/server.crt")
})
end
end
end
require 'rails/commands'
Note: for those who might be wondering, I created an 'ssllocal' directory off my root application directory, and that's where I store the ssl keys and certs.
You could try just requiring the debugger yourself in your development environment.
In your Gemfile:
if RUBY_VERSION =~ /^1.9/
gem "ruby-debug19", :group => :development
else
gem "ruby-debug", :group => :development
end
And within the config block of your config/environments/development.rb:
require 'ruby-debug'
Debugger.start
This permits you to place the debugger statement anywhere in your code.
Here's my solution - I hacked the Thin TcpServer to load my self-signed SSL certs, only in the development environment. My script/rails looks like this:
#!/usr/bin/env ruby
# This command will automatically be run when you run "rails" with Rails 3 gems installed from the root of your application.
APP_PATH = File.expand_path('../../config/application', __FILE__)
require File.expand_path('../../config/boot', __FILE__)
# Hack our SSL certs into Thin TcpServer, only in development environment
require 'thin'
module Thin
module Backends
TcpServer.class_eval do
def initialize_with_SSL(host, port)
if Rails.env.development?
Rails.logger.info "Loading SSL certs from ./ssl_dev..."
#ssl = true
#ssl_options = {
:private_key_file => File.expand_path("../../ssl_dev/server.key", __FILE__),
:cert_chain_file => File.expand_path("../../ssl_dev/server.crt", __FILE__),
:verify_peer => nil
}
end
initialize_without_SSL(host, port)
end
alias_method :initialize_without_SSL, :initialize
alias_method :initialize, :initialize_with_SSL
end
end
end
# Must load 'rails/commands' after Thin SSL hack
require 'rails/commands'
Here's how I got it to finally work on production using Thin:
rvmsudo thin start -p 443 --ssl --ssl-key-file ssl/server.key --ssl-cert-file ssl/server.crt
If you are having issues with your KEY file, make sure you validate the CSR by using a site like:
https://ssl-tools.verisign.com
If your CSR fails, then the certificate you receive from your signing authority will fail too.
My site would refuse to load with the SSL certs, only to find out that I abbreviated my State name to "TX" instead of "Texas" while creating my private key. That was the reason it wasn't working all along! SSL certs are a pain in the ass!
I was able to successfully get the debugging working with ssl enabled thin, using the solution suggested by nathan. Though I had to do one small change of deferring initialization of #ssl after the call of initialize_without_ssl (an alias method for the original TcpServer's initialize)
require 'thin'
module Thin
module Backends
TcpServer.class_eval do
def initialize_with_SSL(host, port)
if Rails.env.development?
Rails.logger.info "Loading SSL certs from ./ssl_dev..."
#ssl_options = {
:private_key_file => File.expand_path("../../ssl_dev/server.key", __FILE__),
:cert_chain_file => File.expand_path("../../ssl_dev/server.crt", __FILE__),
:verify_peer => nil
}
end
initialize_without_SSL(host, port)
# #ssl initialized after calling the original initialize of TcpServer
#ssl = true if Rails.env.development?
end
alias_method :initialize_without_SSL, :initialize
alias_method :initialize, :initialize_with_SSL
end
end
end
alias_method :initialize_without_SSL, :initialize
alias_method :initialize, :initialize_with_SSL
end
In the above code snippett, #ssl is set to true after calling the original initialize call of Thin::Backend::TcpServer. I had to do this since the TcpServer invokes its parent's initialize (Thin::Backend:Base) that sets the #ssl to nil
#Base initialize method. Thin gem version 1.5.0
def initialize
#connections = []
#timeout = Server::DEFAULT_TIMEOUT
#persistent_connection_count = 0
#maximum_connections = Server::DEFAULT_MAXIMUM_CONNECTIONS
#maximum_persistent_connections = Server::DEFAULT_MAXIMUM_PERSISTENT_CONNECTIONS
#no_epoll = false
#ssl = nil
#threaded = nil
end
As noted in nathan's code block, the whole solution appears to be a hack around. In my opinion, I am fine with the snippet considering the code is done within the context of env.development and most importantly it allows debugging with ssl enabled.