discourse/config/initializers/200-first_middlewares.rb

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

123 lines
4.3 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
# we want MessageBus to be close to the front
# this is important cause the vast majority of web requests go to it
# this allows us to avoid full middleware crawls each time
#
# We aren't manipulating the middleware stack directly because of
# https://github.com/rails/rails/pull/27936
require "middleware/processing_request"
Rails.configuration.middleware.unshift(Middleware::ProcessingRequest)
Rails.configuration.middleware.unshift(MessageBus::Rack::Middleware)
# no reason to track this in development, that is 300+ redis calls saved per
# page view (we serve all assets out of thin in development)
if Rails.env != "development" || ENV["TRACK_REQUESTS"]
require "middleware/request_tracker"
Rails.configuration.middleware.unshift(Middleware::RequestTracker)
Rails.configuration.middleware.move_before(Middleware::RequestTracker, ActionDispatch::RemoteIp)
MethodProfiler.ensure_discourse_instrumentation! if GlobalSetting.enable_performance_http_headers
end
if Rails.env.test?
# In test mode we can't insert/remove middlewares
# Therefore we insert a small helper which effectively switches the multisite
# middleware on/off based on the Rails.configuration.multisite value
class TestMultisiteMiddleware < RailsMultisite::Middleware
def call(env)
return @app.call(env) if !Rails.configuration.multisite
super(env)
end
end
Rails.configuration.middleware.unshift TestMultisiteMiddleware,
RailsMultisite::DiscoursePatches.config
class BlockRequestsMiddleware
DEV: Do not process requests initiated by browser in a different example (#25809) Why this change? We noticed that running `LOAD_PLUGINS=1 rspec --seed=38855 plugins/chat/spec/system/chat_new_message_spec.rb` locally results in the system tests randomly failing. When we inspected the request logs closely, we noticed that a `/presence/get` request from a previous rspec example was being processed when a new rspec example is already being run. We know it was from the previous rspec example because inspecting the auth token showed the request using the auth token of a user from the previous example. However, when a request using an auth token from a previous example is used it ends up logging out the same user on the server side because the user id in the cookie is the same due to the use of `fab!`. I did some research and there is apparently no way to wait until all inflight requests by the browser has completed through capybara or selenium. Therefore, we will add an identifier by attaching a cookie to all non-xhr requests so that xhr requests which are triggered subsequently will contain the cookie in the request. In the `BlockRequestsMiddleware` middleware, we will then reject any requests when the value of the identifier in the cookie does not match the current rspec's example location. To see the problem locally, change `Auth::DefaultCurrentUserProvider.find_v1_auth_cookie` to the following: ``` def self.find_v1_auth_cookie(env) return env[DECRYPTED_AUTH_COOKIE] if env.key?(DECRYPTED_AUTH_COOKIE) env[DECRYPTED_AUTH_COOKIE] = begin request = ActionDispatch::Request.new(env) cookie = request.cookies[TOKEN_COOKIE] # don't even initialize a cookie jar if we don't have a cookie at all if cookie&.valid_encoding? && cookie.present? puts "#{env["REQUEST_PATH"]} #{request.cookie_jar.encrypted[TOKEN_COOKIE]&.with_indifferent_access}" request.cookie_jar.encrypted[TOKEN_COOKIE]&.with_indifferent_access end end end ``` After which run the following command: `LOAD_PLUGINS=1 rspec --format documentation --seed=38855 plugins/chat/spec/system/chat_new_message_spec.rb` It takes a few tries but the last spec should fail and you should see something like this: ``` assets/chunk.c16f6ba8b6824baa47ac.d41d8cd9.js {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735} /assets/chunk.050148142e1d2dc992dd.d41d8cd9.js {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735} /chat/api/channels/527/messages {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735} /uploads/default/test_0/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_512x512.png {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735} redirects to existing chat channel redirects to chat channel if recipients param is missing (PENDING: Temporarily skipped with xit) with multiple users /favicon.ico {"token"=>"9a75c114c4d3401509a23d240f0a46d4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591736} /chat/new-message {"token"=>"9a75c114c4d3401509a23d240f0a46d4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591736} /presence/get {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735} ``` Note how the `/presence/get` request is using a token from the previous example. Co-authored-by: David Taylor <david@taylorhq.com>
2024-02-22 19:41:10 +08:00
RSPEC_CURRENT_EXAMPLE_COOKIE_STRING = "rspec_current_example_location"
cattr_accessor :current_example_location
@@block_requests = false
def self.block_requests!
@@block_requests = true
end
def self.allow_requests!
@@block_requests = false
end
def initialize(app)
@app = app
end
def call(env)
DEV: Do not process requests initiated by browser in a different example (#25809) Why this change? We noticed that running `LOAD_PLUGINS=1 rspec --seed=38855 plugins/chat/spec/system/chat_new_message_spec.rb` locally results in the system tests randomly failing. When we inspected the request logs closely, we noticed that a `/presence/get` request from a previous rspec example was being processed when a new rspec example is already being run. We know it was from the previous rspec example because inspecting the auth token showed the request using the auth token of a user from the previous example. However, when a request using an auth token from a previous example is used it ends up logging out the same user on the server side because the user id in the cookie is the same due to the use of `fab!`. I did some research and there is apparently no way to wait until all inflight requests by the browser has completed through capybara or selenium. Therefore, we will add an identifier by attaching a cookie to all non-xhr requests so that xhr requests which are triggered subsequently will contain the cookie in the request. In the `BlockRequestsMiddleware` middleware, we will then reject any requests when the value of the identifier in the cookie does not match the current rspec's example location. To see the problem locally, change `Auth::DefaultCurrentUserProvider.find_v1_auth_cookie` to the following: ``` def self.find_v1_auth_cookie(env) return env[DECRYPTED_AUTH_COOKIE] if env.key?(DECRYPTED_AUTH_COOKIE) env[DECRYPTED_AUTH_COOKIE] = begin request = ActionDispatch::Request.new(env) cookie = request.cookies[TOKEN_COOKIE] # don't even initialize a cookie jar if we don't have a cookie at all if cookie&.valid_encoding? && cookie.present? puts "#{env["REQUEST_PATH"]} #{request.cookie_jar.encrypted[TOKEN_COOKIE]&.with_indifferent_access}" request.cookie_jar.encrypted[TOKEN_COOKIE]&.with_indifferent_access end end end ``` After which run the following command: `LOAD_PLUGINS=1 rspec --format documentation --seed=38855 plugins/chat/spec/system/chat_new_message_spec.rb` It takes a few tries but the last spec should fail and you should see something like this: ``` assets/chunk.c16f6ba8b6824baa47ac.d41d8cd9.js {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735} /assets/chunk.050148142e1d2dc992dd.d41d8cd9.js {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735} /chat/api/channels/527/messages {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735} /uploads/default/test_0/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_512x512.png {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735} redirects to existing chat channel redirects to chat channel if recipients param is missing (PENDING: Temporarily skipped with xit) with multiple users /favicon.ico {"token"=>"9a75c114c4d3401509a23d240f0a46d4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591736} /chat/new-message {"token"=>"9a75c114c4d3401509a23d240f0a46d4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591736} /presence/get {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735} ``` Note how the `/presence/get` request is using a token from the previous example. Co-authored-by: David Taylor <david@taylorhq.com>
2024-02-22 19:41:10 +08:00
request = Rack::Request.new(env)
if (
@@block_requests ||
(
request.xhr? && self.class.current_example_location.present? &&
self.class.current_example_location !=
request.cookies[RSPEC_CURRENT_EXAMPLE_COOKIE_STRING]
)
)
return [
DEV: Ensure that `BlockRequestsMiddleware` cookie is always set (#25826) Why this change? This reverts 725561cf4bddeda0a5cf2f68ed7b76e0c9deead8 as it did not address the root cause of the problem even though it fixed the failing tests we were seeing when running `bundle exec rspec --tag ~type:multisite --order random:776 spec/system/admin_customize_form_templates_spec.rb spec/system/admin_sidebar_navigation_spec.rb spec/system/admin_site_setting_search_spec.rb spec/system/composer/dont_feed_the_trolls_popup_spec.rb spec/system/composer/review_media_unless_trust_level_spec.rb spec/system/create_account_spec.rb spec/system/editing_sidebar_tags_navigation_spec.rb spec/system/email_change_spec.rb spec/system/emojis/emoji_deny_list_spec.rb spec/system/group_activity_spec.rb spec/system/hashtag_autocomplete_spec.rb spec/system/network_disconnected_spec.rb spec/system/post_menu_spec.rb spec/system/post_small_action_spec.rb spec/system/tags_intersection_spec.rb spec/system/topic_list_focus_spec.rb spec/system/topic_page_spec.rb spec/system/user_page/user_profile_info_panel_spec.rb spec/system/viewing_group_members_spec.rb spec/system/viewing_navigation_menu_preferences_spec.rb`. The root cause here is that `before_action`s added to a controller is order dependent. As such, some requests were not setting the cookie because the `before_action` callback was not even hit as a prior `before_action` callbacks has raised an error such as the `check_xhr` `before_action` callback. To resolve the problem, we need to add the `prepend: true` option in our monkey patch of `ApplicationController` to ensure that the `before_action` callback which we have added is always run first. This change also makes a couple of changes: 1. Improve the response body when a request is blocked by the `BlockRequestsMiddleware` middleware so that it makes debugging easier. 2. Only set the cookies for non-xhr HTML format requests. Setting it for other formats is kind of pointless.
2024-02-23 07:51:51 +08:00
503,
{ "Content-Type" => "text/plain" },
[
"Blocked by BlockRequestsMiddleware for requests initiated by #{request.cookies[RSPEC_CURRENT_EXAMPLE_COOKIE_STRING]} when running #{self.class.current_example_location}",
]
DEV: Ensure that `BlockRequestsMiddleware` cookie is always set (#25826) Why this change? This reverts 725561cf4bddeda0a5cf2f68ed7b76e0c9deead8 as it did not address the root cause of the problem even though it fixed the failing tests we were seeing when running `bundle exec rspec --tag ~type:multisite --order random:776 spec/system/admin_customize_form_templates_spec.rb spec/system/admin_sidebar_navigation_spec.rb spec/system/admin_site_setting_search_spec.rb spec/system/composer/dont_feed_the_trolls_popup_spec.rb spec/system/composer/review_media_unless_trust_level_spec.rb spec/system/create_account_spec.rb spec/system/editing_sidebar_tags_navigation_spec.rb spec/system/email_change_spec.rb spec/system/emojis/emoji_deny_list_spec.rb spec/system/group_activity_spec.rb spec/system/hashtag_autocomplete_spec.rb spec/system/network_disconnected_spec.rb spec/system/post_menu_spec.rb spec/system/post_small_action_spec.rb spec/system/tags_intersection_spec.rb spec/system/topic_list_focus_spec.rb spec/system/topic_page_spec.rb spec/system/user_page/user_profile_info_panel_spec.rb spec/system/viewing_group_members_spec.rb spec/system/viewing_navigation_menu_preferences_spec.rb`. The root cause here is that `before_action`s added to a controller is order dependent. As such, some requests were not setting the cookie because the `before_action` callback was not even hit as a prior `before_action` callbacks has raised an error such as the `check_xhr` `before_action` callback. To resolve the problem, we need to add the `prepend: true` option in our monkey patch of `ApplicationController` to ensure that the `before_action` callback which we have added is always run first. This change also makes a couple of changes: 1. Improve the response body when a request is blocked by the `BlockRequestsMiddleware` middleware so that it makes debugging easier. 2. Only set the cookies for non-xhr HTML format requests. Setting it for other formats is kind of pointless.
2024-02-23 07:51:51 +08:00
]
end
status, headers, body = @app.call(env)
if headers["Content-Type"]&.match?(/html/) && BlockRequestsMiddleware.current_example_location
headers["Set-Cookie"] = [
headers["Set-Cookie"],
"#{RSPEC_CURRENT_EXAMPLE_COOKIE_STRING}=#{BlockRequestsMiddleware.current_example_location}; path=/;",
].compact.join("\n")
end
[status, headers, body]
end
end
Rails.configuration.middleware.unshift BlockRequestsMiddleware
elsif Rails.configuration.multisite
assets_hostnames = GlobalSetting.cdn_hostnames
if assets_hostnames.empty?
assets_hostnames = Discourse::Application.config.database_configuration[Rails.env]["host_names"]
end
RailsMultisite::ConnectionManagement.asset_hostnames = assets_hostnames
# Multisite needs to be first, because the request tracker and message bus rely on it
Rails.configuration.middleware.unshift RailsMultisite::Middleware,
RailsMultisite::DiscoursePatches.config
Rails.configuration.middleware.delete ActionDispatch::Executor
if defined?(RailsFailover::ActiveRecord) && Rails.configuration.active_record_rails_failover
Rails.configuration.middleware.insert_after(
RailsMultisite::Middleware,
RailsFailover::ActiveRecord::Middleware,
)
end
if Rails.env.development?
# Automatically allow development multisite hosts
RailsMultisite::ConnectionManagement.instance.db_spec_cache.each do |db, specification|
next if db == "default"
Rails.configuration.hosts.concat(specification.spec.configuration_hash[:host_names])
end
end
elsif defined?(RailsFailover::ActiveRecord) && Rails.configuration.active_record_rails_failover
Rails.configuration.middleware.insert_before(
MessageBus::Rack::Middleware,
RailsFailover::ActiveRecord::Middleware,
)
end