使用Apache和Passenger為Rails 4.2站點設置SSL的問題

Question

我正在使用Apache（2.4.7）和Passenger 5.1.1管理在Ubuntu 14.04上運行的Rails（4.2）站點。 我正在使用Cloudflare證書設置SSL。

該網站似乎正在運行，並且在瀏覽器中沒有出現任何SSL錯誤，但是在我的應用程序日志中，我看到內部資源（通常在供應商或公共部門）出現404（ActionController :: RoutingError）錯誤的負載。

我不知道是什么原因導致此錯誤。 我已經嘗試在production.rb文件中設置“ config.force_ssl = true”，但是據我所知，我應該能夠從Apache或Cloudflare對此進行管理。

任何人都可以幫助我，甚至只是給我一些線索，因為此刻，我很茫然。

Started GET "/example/vendor/bundle/ruby/2.3.0/gems/posix-spawn-0.3.12/test/" for xxx.xxx.xxx.xx at 2017-09-25 21:14:37 +0100

ActionController::RoutingError (No route matches [GET] "/mysite/vendor/bundle/ruby/2.3.0/gems/posix-spawn-0.3.12/test"):
  vendor/bundle/ruby/2.3.0/gems/actionpack-4.2.0/lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
  vendor/bundle/ruby/2.3.0/gems/newrelic_rpm-3.17.1.326/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'
  vendor/bundle/ruby/2.3.0/gems/actionpack-4.2.0/lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
  vendor/bundle/ruby/2.3.0/gems/newrelic_rpm-3.17.1.326/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'
  vendor/bundle/ruby/2.3.0/gems/railties-4.2.0/lib/rails/rack/logger.rb:38:in `call_app'
  vendor/bundle/ruby/2.3.0/gems/railties-4.2.0/lib/rails/rack/logger.rb:20:in `block in call'
  vendor/bundle/ruby/2.3.0/gems/activesupport-4.2.0/lib/active_support/tagged_logging.rb:68:in `block in tagged'
  vendor/bundle/ruby/2.3.0/gems/activesupport-4.2.0/lib/active_support/tagged_logging.rb:26:in `tagged'
  vendor/bundle/ruby/2.3.0/gems/activesupport-4.2.0/lib/active_support/tagged_logging.rb:68:in `tagged'
  vendor/bundle/ruby/2.3.0/gems/railties-4.2.0/lib/rails/rack/logger.rb:20:in `call'
  vendor/bundle/ruby/2.3.0/gems/newrelic_rpm-3.17.1.326/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'
  vendor/bundle/ruby/2.3.0/gems/actionpack-4.2.0/lib/action_dispatch/middleware/request_id.rb:21:in `call'
  vendor/bundle/ruby/2.3.0/gems/newrelic_rpm-3.17.1.326/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'
  vendor/bundle/ruby/2.3.0/gems/rack-1.6.5/lib/rack/methodoverride.rb:22:in `call'
  vendor/bundle/ruby/2.3.0/gems/newrelic_rpm-3.17.1.326/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'
  vendor/bundle/ruby/2.3.0/gems/rack-1.6.5/lib/rack/runtime.rb:18:in `call'
  vendor/bundle/ruby/2.3.0/gems/newrelic_rpm-3.17.1.326/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'
  vendor/bundle/ruby/2.3.0/gems/activesupport-4.2.0/lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
  vendor/bundle/ruby/2.3.0/gems/newrelic_rpm-3.17.1.326/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'
  vendor/bundle/ruby/2.3.0/gems/rack-1.6.5/lib/rack/sendfile.rb:113:in `call'
  vendor/bundle/ruby/2.3.0/gems/newrelic_rpm-3.17.1.326/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'
  vendor/bundle/ruby/2.3.0/gems/railties-4.2.0/lib/rails/engine.rb:518:in `call'
  vendor/bundle/ruby/2.3.0/gems/railties-4.2.0/lib/rails/application.rb:164:in `call'
  vendor/bundle/ruby/2.3.0/gems/railties-4.2.0/lib/rails/railtie.rb:194:in `public_send'
  vendor/bundle/ruby/2.3.0/gems/railties-4.2.0/lib/rails/railtie.rb:194:in `method_missing'
  vendor/bundle/ruby/2.3.0/gems/newrelic_rpm-3.17.1.326/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'
  /home/mysite/.rvm/gems/ruby-2.3.3@2.3.3on4.2/gems/passenger-5.1.1/src/ruby_supportlib/phusion_passenger/rack/thread_handler_extension.rb:97:in `process_request'
  /home/mysite/.rvm/gems/ruby-2.3.3@2.3.3on4.2/gems/passenger-5.1.1/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:152:in `accept_and_process_next_request'
  /home/mysite/.rvm/gems/ruby-2.3.3@2.3.3on4.2/gems/passenger-5.1.1/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:113:in `main_loop'
  /home/mysite/.rvm/gems/ruby-2.3.3@2.3.3on4.2/gems/passenger-5.1.1/src/ruby_supportlib/phusion_passenger/request_handler.rb:416:in `block (3 levels) in start_threads'
  /home/mysite/.rvm/gems/ruby-2.3.3@2.3.3on4.2/gems/passenger-5.1.1/src/ruby_supportlib/phusion_passenger/utils.rb:113:in `block in create_thread_and_abort_on_exception'

我的Apache配置如下所示：

<VirtualHost *:80>

  ServerName example.com

  RewriteEngine On
  RewriteCond %{HTTPS} off [OR]
  RewriteCond %{HTTP_HOST} !^www\. [NC]
  RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
  RewriteRule ^ https://www.%1%{REQUEST_URI} [L,NE,R=301]

</VirtualHost>

<VirtualHost *:80>

  ServerName www.example.com

  RewriteEngine On
  RewriteCond %{HTTPS} off [OR]
  RewriteCond %{HTTP_HOST} !^www\. [NC]
  RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
  RewriteRule ^ https://www.%1%{REQUEST_URI} [L,NE,R=301]

</VirtualHost>

<VirtualHost *:443>

  RequestHeader set X-Forwarded-Proto "https"
  SSLEngine      on
  SSLCertificateFile        /home/example/ssl/example.crt
  SSLCertificateKeyFile     /home/example/ssl/example.key

  ServerName example.com

  # Redirect / https://www.example.com/
  RewriteEngine On
  RewriteCond %{HTTPS} off [OR]
  RewriteCond %{HTTP_HOST} !^www\. [NC]
  RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
  RewriteRule ^ https://www.%1%{REQUEST_URI} [L,NE,R=301]

</VirtualHost>

<VirtualHost *:443>
  RequestHeader set X-Forwarded-Proto "https"
  SSLEngine      on
  SSLCertificateFile        /home/example/ssl/example.crt
  SSLCertificateKeyFile     /home/example/ssl/example.key

  ServerName www.example.com
  ServerAdmin dagmar@example.com 
  DocumentRoot /var/www/example/public 
  ErrorLog /var/log/apache2/example/error.log 
  CustomLog /var/log/apache2/example/access.log common 

  <Directory /var/www/example/public>
    # This relaxes Apache security settings.
    AllowOverride all
    # MultiViews must be turned off.
    Options -MultiViews
  </Directory>

//等

</VirtualHost>

Answer 1

提出的請求引用了非公共路徑。 即/example/vendor/bundle/ruby/2.3.0/gems/posix-spawn-0.3.12/test/這不是SSL問題。 檢查您的訪問日志，以查看是否有這樣的請求，是否是應用程序的問題，如果不是，則是重定向的問題。

Answer 2

所以這是一個錯誤的喜劇。 我想分享一下我的發現，以便也許我可以省下很多小時的挫敗感。

首先，上面的設置並沒有多大錯，盡管有點冗長。

這是我使用的最終conf文件：

# avoids sending hackers too much info about the server
ServerTokens Prod

# Necessary if you have more than one domain served from this webserver
SSLStrictSNIVHostCheck off

RewriteEngine On

# redirects http to https and root domain to www
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,NE,R=301]

# sets the HTTPS header for Wordpress
SetEnvIf X-Forwarded-Proto https HTTPS=on

<VirtualHost _default_:443>

  ServerName www.example.com
  ServerAdmin dagmar@example.com

  ErrorLog /var/log/apache2/example/error.log
  CustomLog /var/log/apache2/example/access.log common

  DocumentRoot "/var/www/example/public"
  <Directory "/var/www/example/public">
    Options None
    Require all granted
  </Directory>

  PassengerAppEnv production
  PassengerAppRoot "/var/www/example"
  PassengerHighPerformance on

  SSLEngine      on
  SSLCertificateFile        /home/example/ssl/example.crt
  SSLCertificateKeyFile     /home/example/ssl/example.key

  ServerSignature off

  ProxyRequests Off
  ProxyPreserveHost On

  # blog reverse proxy which goes over http
  ProxyPass /blog http://www.example.com:8080/blog
  ProxyPassReverse /blog http://www.example.com:8080/blog

</VirtualHost>

我發現兩個非常有助於正確配置Apache的網頁：

1. https://simonecarletti.com/blog/2016/08/redirect-domain-http-https-www-apache/
2. https://www.phusionpassenger.com/library/deploy/apache/prod_ssl.html

雲耀斑

由於我使用的是Cloudflare，因此我也使用Cloudflare頁面規則將https://example.com/*重定向到https://www.example.com 。 有關更多詳細信息，請參見此博客 。 注意：我不需要清除緩存就可以使用此解決方案。

我還使用Cloudflare通過“ Cypro”設置頁面上的切換來管理從HTTP到https的重定向。

最后，關於我一直在努力的問題...

我的日志文件中的內部URL有問題

（我認為）這是由於先前對Apache的錯誤配置引起的，這些文件是公開的，並由Google索引（多么令人尷尬）。 我認為可能是我使用的Apache PageSpeed mod。

我在上面的VirtualHost定義中添加了“ gone”重定向，以避免在搜索引擎停止為這些文件編制索引之前，我的日志文件被阻塞。

  Redirect gone /example/

將http重定向到https並將根域重定向到www的問題

這太麻煩了……無論我使用哪種Apache配置，我一生都無法獲得根域的正確重定向。 我在瀏覽器中收到安全警告，但是當我使用SSL檢查器站點檢查域時，他們都說站點配置正確。 最后，我意識到我已經在我的/ etc / hosts文件中（在我的筆記本電腦上）輸入了服務器URL，以便通過Cloudflare代理輕松地將SSH連接到服務器...因此，當我打算https://example.com，它是直接命中服務器，而不是通過Cloudflare。

反向代理上的Wordpress問題

WordPress虛擬主機（運行在8080上）不需要SSL，因為它位於根域之后，但是您需要將儀表板中的URL更改為https://www.example.com/blog 。

如果在將所有URL更改為https之前破壞了儀表板（就像我所做的那樣），則需要手動進行URL更改

1. 在數據庫中的表wp_options中。 該查詢將很有幫助： select * from wp_options where option_value like 'http://www.example.com%';
2. 並在wp-config.php中（請參閱條目WP_HOME和WP_SITEURL）。

您還需要對wp-config.php進行一些更改（我確實做了），以使儀表板在升級到SSL后可以工作。 我在wp-config.php的末尾添加了以下代碼：

define('FORCE_SSL_ADMIN', true);
// in some setups HTTP_X_FORWARDED_PROTO might contain 
// a comma-separated list e.g. http,https
// so check for https existence
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
    $_SERVER['HTTPS'] = 'on';

請注意，Apache配置中的這一行也很重要：

SetEnvIf X-Forwarded-Proto https HTTPS=on

得到教訓

1. 保留許多Apache配置的備份
2. 確保您的/ etc / hosts文件是干凈的
3. 為避免必須清除瀏覽器緩存，請使用隱身窗口和專用窗口