2017-10-17 21:10:12 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2018-12-30 18:53:30 -05:00
|
|
|
require "method_profiler"
|
|
|
|
require "middleware/anonymous_cache"
|
2024-05-23 21:49:17 -04:00
|
|
|
require "http_user_agent_encoder"
|
2015-02-05 00:08:52 -05:00
|
|
|
|
|
|
|
class Middleware::RequestTracker
|
2017-10-17 21:10:12 -04:00
|
|
|
@@detailed_request_loggers = nil
|
2018-02-05 17:45:25 -05:00
|
|
|
@@ip_skipper = nil
|
2017-10-17 21:10:12 -04:00
|
|
|
|
2021-08-13 11:00:23 -04:00
|
|
|
# You can add exceptions to our app rate limiter in the app.yml ENV section.
|
|
|
|
# example:
|
|
|
|
#
|
|
|
|
# env:
|
|
|
|
# DISCOURSE_MAX_REQS_PER_IP_EXCEPTIONS: >-
|
|
|
|
# 14.15.16.32/27
|
|
|
|
# 216.148.1.2
|
|
|
|
#
|
|
|
|
STATIC_IP_SKIPPER =
|
|
|
|
ENV["DISCOURSE_MAX_REQS_PER_IP_EXCEPTIONS"]&.split&.map { |ip| IPAddr.new(ip) }
|
|
|
|
|
2017-10-17 21:10:12 -04:00
|
|
|
# register callbacks for detailed request loggers called on every request
|
|
|
|
# example:
|
|
|
|
#
|
|
|
|
# Middleware::RequestTracker.detailed_request_logger(->|env, data| do
|
|
|
|
# # do stuff with env and data
|
|
|
|
# end
|
|
|
|
def self.register_detailed_request_logger(callback)
|
2019-03-05 06:19:11 -05:00
|
|
|
MethodProfiler.ensure_discourse_instrumentation!
|
2017-10-17 21:10:12 -04:00
|
|
|
(@@detailed_request_loggers ||= []) << callback
|
|
|
|
end
|
|
|
|
|
|
|
|
def self.unregister_detailed_request_logger(callback)
|
2021-01-19 04:35:46 -05:00
|
|
|
@@detailed_request_loggers.delete(callback)
|
2017-10-17 21:10:12 -04:00
|
|
|
@detailed_request_loggers = nil if @@detailed_request_loggers.length == 0
|
2018-02-05 17:45:25 -05:00
|
|
|
end
|
2017-10-17 21:10:12 -04:00
|
|
|
|
2018-02-05 18:38:15 -05:00
|
|
|
# used for testing
|
|
|
|
def self.unregister_ip_skipper
|
|
|
|
@@ip_skipper = nil
|
|
|
|
end
|
|
|
|
|
2018-02-05 17:45:25 -05:00
|
|
|
# Register a custom `ip_skipper`, a function that will skip rate limiting
|
|
|
|
# for any IP that returns true.
|
|
|
|
#
|
|
|
|
# For example, if you never wanted to rate limit 1.2.3.4
|
|
|
|
#
|
|
|
|
# ```
|
|
|
|
# Middleware::RequestTracker.register_ip_skipper do |ip|
|
|
|
|
# ip == "1.2.3.4"
|
|
|
|
# end
|
|
|
|
# ```
|
|
|
|
def self.register_ip_skipper(&blk)
|
2018-02-05 18:38:15 -05:00
|
|
|
raise "IP skipper is already registered!" if @@ip_skipper
|
2018-02-05 17:45:25 -05:00
|
|
|
@@ip_skipper = blk
|
2017-10-17 21:10:12 -04:00
|
|
|
end
|
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
def self.ip_skipper
|
|
|
|
@@ip_skipper
|
|
|
|
end
|
|
|
|
|
2015-02-05 00:08:52 -05:00
|
|
|
def initialize(app, settings = {})
|
|
|
|
@app = app
|
|
|
|
end
|
|
|
|
|
2015-02-10 01:03:33 -05:00
|
|
|
def self.log_request(data)
|
2022-11-29 06:07:42 -05:00
|
|
|
if data[:is_api]
|
|
|
|
ApplicationRequest.increment!(:api)
|
|
|
|
elsif data[:is_user_api]
|
|
|
|
ApplicationRequest.increment!(:user_api)
|
|
|
|
elsif data[:track_view]
|
2015-02-10 01:03:33 -05:00
|
|
|
if data[:is_crawler]
|
2015-02-05 22:39:04 -05:00
|
|
|
ApplicationRequest.increment!(:page_view_crawler)
|
2018-03-15 17:10:45 -04:00
|
|
|
WebCrawlerRequest.increment!(data[:user_agent])
|
2015-02-10 01:03:33 -05:00
|
|
|
elsif data[:has_auth_cookie]
|
2015-02-05 22:39:04 -05:00
|
|
|
ApplicationRequest.increment!(:page_view_logged_in)
|
2015-07-03 17:02:57 -04:00
|
|
|
ApplicationRequest.increment!(:page_view_logged_in_mobile) if data[:is_mobile]
|
2024-07-02 20:38:49 -04:00
|
|
|
|
2024-04-25 06:00:01 -04:00
|
|
|
if data[:explicit_track_view]
|
|
|
|
# Must be a browser if it had this header from our ajax implementation
|
|
|
|
ApplicationRequest.increment!(:page_view_logged_in_browser)
|
|
|
|
ApplicationRequest.increment!(:page_view_logged_in_browser_mobile) if data[:is_mobile]
|
2024-07-02 20:38:49 -04:00
|
|
|
|
|
|
|
if data[:topic_id].present? && data[:current_user_id].present?
|
|
|
|
TopicsController.defer_topic_view(
|
|
|
|
data[:topic_id],
|
|
|
|
data[:request_remote_ip],
|
|
|
|
data[:current_user_id],
|
|
|
|
)
|
|
|
|
end
|
2024-04-25 06:00:01 -04:00
|
|
|
end
|
2021-04-26 07:19:47 -04:00
|
|
|
elsif !SiteSetting.login_required
|
2015-02-05 22:39:04 -05:00
|
|
|
ApplicationRequest.increment!(:page_view_anon)
|
2015-07-03 17:02:57 -04:00
|
|
|
ApplicationRequest.increment!(:page_view_anon_mobile) if data[:is_mobile]
|
2024-07-02 20:38:49 -04:00
|
|
|
|
2024-04-25 06:00:01 -04:00
|
|
|
if data[:explicit_track_view]
|
|
|
|
# Must be a browser if it had this header from our ajax implementation
|
|
|
|
ApplicationRequest.increment!(:page_view_anon_browser)
|
|
|
|
ApplicationRequest.increment!(:page_view_anon_browser_mobile) if data[:is_mobile]
|
2024-07-02 20:38:49 -04:00
|
|
|
|
|
|
|
if data[:topic_id].present?
|
|
|
|
TopicsController.defer_topic_view(data[:topic_id], data[:request_remote_ip])
|
|
|
|
end
|
2024-04-25 06:00:01 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
# Message-bus requests may include this 'deferred track' header which we use to detect
|
|
|
|
# 'real browser' views.
|
|
|
|
if data[:deferred_track] && !data[:is_crawler]
|
|
|
|
if data[:has_auth_cookie]
|
|
|
|
ApplicationRequest.increment!(:page_view_logged_in_browser)
|
|
|
|
ApplicationRequest.increment!(:page_view_logged_in_browser_mobile) if data[:is_mobile]
|
2024-07-02 20:38:49 -04:00
|
|
|
|
|
|
|
if data[:topic_id].present? && data[:current_user_id].present?
|
|
|
|
TopicsController.defer_topic_view(
|
|
|
|
data[:topic_id],
|
|
|
|
data[:request_remote_ip],
|
|
|
|
data[:current_user_id],
|
|
|
|
)
|
|
|
|
end
|
2024-04-25 06:00:01 -04:00
|
|
|
elsif !SiteSetting.login_required
|
|
|
|
ApplicationRequest.increment!(:page_view_anon_browser)
|
|
|
|
ApplicationRequest.increment!(:page_view_anon_browser_mobile) if data[:is_mobile]
|
2024-07-02 20:38:49 -04:00
|
|
|
|
|
|
|
if data[:topic_id].present?
|
|
|
|
TopicsController.defer_topic_view(data[:topic_id], data[:request_remote_ip])
|
|
|
|
end
|
2015-02-05 22:39:04 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
ApplicationRequest.increment!(:http_total)
|
|
|
|
|
2022-11-29 06:07:42 -05:00
|
|
|
status = data[:status]
|
2015-02-05 22:39:04 -05:00
|
|
|
if status >= 500
|
|
|
|
ApplicationRequest.increment!(:http_5xx)
|
2015-02-11 17:47:32 -05:00
|
|
|
elsif data[:is_background]
|
|
|
|
ApplicationRequest.increment!(:http_background)
|
2015-02-05 22:39:04 -05:00
|
|
|
elsif status >= 400
|
|
|
|
ApplicationRequest.increment!(:http_4xx)
|
|
|
|
elsif status >= 300
|
|
|
|
ApplicationRequest.increment!(:http_3xx)
|
2021-01-19 04:35:46 -05:00
|
|
|
elsif status >= 200
|
2015-02-11 17:47:32 -05:00
|
|
|
ApplicationRequest.increment!(:http_2xx)
|
2015-02-05 00:08:52 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
def self.get_data(env, result, timing, request = nil)
|
2015-02-10 01:03:33 -05:00
|
|
|
status, headers = result
|
2024-05-08 11:08:39 -04:00
|
|
|
|
|
|
|
# result may be nil if the downstream app raised an exception
|
2015-02-10 01:03:33 -05:00
|
|
|
status = status.to_i
|
2024-05-08 11:08:39 -04:00
|
|
|
headers ||= {}
|
2015-02-10 01:03:33 -05:00
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
request ||= Rack::Request.new(env)
|
|
|
|
helper = Middleware::AnonymousCache::Helper.new(env, request)
|
2015-02-25 19:40:57 -05:00
|
|
|
|
2024-07-02 20:38:49 -04:00
|
|
|
# Since ActionDispatch::RemoteIp middleware is run before this middleware,
|
|
|
|
# we have access to the normalised remote IP based on ActionDispatch::RemoteIp::GetIp
|
|
|
|
#
|
|
|
|
# NOTE: Locally with MessageBus requests, the remote IP ends up as ::1 because
|
|
|
|
# of the X-Forwarded-For header set...somewhere, whereas all other requests
|
|
|
|
# end up as 127.0.0.1.
|
|
|
|
request_remote_ip = env["action_dispatch.remote_ip"].to_s
|
|
|
|
|
|
|
|
# Value of the discourse-track-view request header, set in `lib/ajax.js`
|
2017-10-17 21:10:12 -04:00
|
|
|
env_track_view = env["HTTP_DISCOURSE_TRACK_VIEW"]
|
2024-04-25 06:00:01 -04:00
|
|
|
|
|
|
|
# Was the discourse-track-view request header set to true? Likely
|
|
|
|
# set by our ajax library to indicate a page view.
|
|
|
|
explicit_track_view = status == 200 && %w[1 true].include?(env_track_view)
|
|
|
|
|
|
|
|
# An HTML response to a GET request is tracked implicitly
|
|
|
|
implicit_track_view =
|
|
|
|
status == 200 && !%w[0 false].include?(env_track_view) && request.get? && !request.xhr? &&
|
|
|
|
headers["Content-Type"] =~ %r{text/html}
|
|
|
|
|
2024-07-02 20:38:49 -04:00
|
|
|
# This header is sent on a follow-up request after a real browser loads up a page
|
|
|
|
# see `scripts/pageview.js` and `instance-initializers/page-tracking.js`
|
|
|
|
deferred_track_view = %w[1 true].include?(env["HTTP_DISCOURSE_DEFERRED_TRACK_VIEW"])
|
|
|
|
|
|
|
|
# This is treated separately from deferred tracking in #log_request, this is
|
|
|
|
# why deferred_track_view is not counted here.
|
2024-04-25 06:00:01 -04:00
|
|
|
track_view = !!(explicit_track_view || implicit_track_view)
|
|
|
|
|
2024-07-02 20:38:49 -04:00
|
|
|
# These are set in the same place as the respective track view headers in the client.
|
|
|
|
topic_id =
|
|
|
|
if deferred_track_view
|
|
|
|
env["HTTP_DISCOURSE_DEFERRED_TRACK_VIEW_TOPIC_ID"]
|
|
|
|
elsif explicit_track_view || implicit_track_view
|
|
|
|
env["HTTP_DISCOURSE_TRACK_VIEW_TOPIC_ID"]
|
|
|
|
end
|
|
|
|
|
|
|
|
auth_cookie = Auth::DefaultCurrentUserProvider.find_v0_auth_cookie(request)
|
|
|
|
auth_cookie ||= Auth::DefaultCurrentUserProvider.find_v1_auth_cookie(env)
|
|
|
|
has_auth_cookie = auth_cookie.present?
|
2015-02-25 19:40:57 -05:00
|
|
|
|
2022-11-29 06:07:42 -05:00
|
|
|
is_api ||= !!env[Auth::DefaultCurrentUserProvider::API_KEY_ENV]
|
|
|
|
is_user_api ||= !!env[Auth::DefaultCurrentUserProvider::USER_API_KEY_ENV]
|
|
|
|
|
2022-02-23 07:45:42 -05:00
|
|
|
is_message_bus = request.path.start_with?("#{Discourse.base_path}/message-bus/")
|
|
|
|
is_topic_timings = request.path.start_with?("#{Discourse.base_path}/topics/timings")
|
|
|
|
|
2024-07-02 20:38:49 -04:00
|
|
|
# Auth cookie can be used to find the ID for logged in users, but API calls must look up the
|
|
|
|
# current user based on env variables.
|
|
|
|
#
|
|
|
|
# We only care about this for topic views, other pageviews it's enough to know if the user is
|
|
|
|
# logged in or not, and we have separate pageview tracking for API views.
|
|
|
|
current_user_id =
|
|
|
|
if topic_id.present?
|
|
|
|
begin
|
|
|
|
(auth_cookie&.[](:user_id) || CurrentUser.lookup_from_env(env)&.id)
|
|
|
|
rescue Discourse::InvalidAccess => err
|
|
|
|
# This error is raised when the API key is invalid, no need to stop the show.
|
|
|
|
Discourse.warn_exception(
|
|
|
|
err,
|
|
|
|
message: "RequestTracker.get_data failed with an invalid API key error",
|
|
|
|
)
|
|
|
|
nil
|
|
|
|
end
|
|
|
|
end
|
2024-04-25 06:00:01 -04:00
|
|
|
|
2019-09-02 04:45:35 -04:00
|
|
|
h = {
|
2015-02-10 01:03:33 -05:00
|
|
|
status: status,
|
|
|
|
is_crawler: helper.is_crawler?,
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
has_auth_cookie: has_auth_cookie,
|
2024-07-02 20:38:49 -04:00
|
|
|
current_user_id: current_user_id,
|
|
|
|
topic_id: topic_id,
|
2022-11-29 06:07:42 -05:00
|
|
|
is_api: is_api,
|
|
|
|
is_user_api: is_user_api,
|
2022-02-23 07:45:42 -05:00
|
|
|
is_background: is_message_bus || is_topic_timings,
|
2015-07-03 17:02:57 -04:00
|
|
|
is_mobile: helper.is_mobile?,
|
2017-10-17 21:10:12 -04:00
|
|
|
track_view: track_view,
|
2018-04-17 04:05:51 -04:00
|
|
|
timing: timing,
|
|
|
|
queue_seconds: env["REQUEST_QUEUE_SECONDS"],
|
2024-04-25 06:00:01 -04:00
|
|
|
explicit_track_view: explicit_track_view,
|
2024-07-02 20:38:49 -04:00
|
|
|
deferred_track: deferred_track_view,
|
|
|
|
request_remote_ip: request_remote_ip,
|
2019-09-02 04:45:35 -04:00
|
|
|
}
|
|
|
|
|
2023-01-06 06:26:18 -05:00
|
|
|
if h[:is_background]
|
|
|
|
h[:background_type] = if is_message_bus
|
|
|
|
if request.query_string.include?("dlp=t")
|
|
|
|
"message-bus-dlp"
|
|
|
|
elsif env["HTTP_DONT_CHUNK"]
|
|
|
|
"message-bus-dontchunk"
|
|
|
|
else
|
|
|
|
"message-bus"
|
|
|
|
end
|
|
|
|
else
|
|
|
|
"topic-timings"
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-09-02 04:45:35 -04:00
|
|
|
if h[:is_crawler]
|
2019-12-09 01:43:51 -05:00
|
|
|
user_agent = env["HTTP_USER_AGENT"]
|
2024-05-23 21:49:17 -04:00
|
|
|
user_agent = HttpUserAgentEncoder.ensure_utf8(user_agent) if user_agent
|
2019-12-09 01:43:51 -05:00
|
|
|
h[:user_agent] = user_agent
|
2019-09-02 04:45:35 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
if cache = headers["X-Discourse-Cached"]
|
|
|
|
h[:cache] = cache
|
2018-03-15 17:10:45 -04:00
|
|
|
end
|
2021-01-19 04:35:46 -05:00
|
|
|
|
2019-09-02 04:45:35 -04:00
|
|
|
h
|
2015-02-10 01:03:33 -05:00
|
|
|
end
|
2015-02-05 00:08:52 -05:00
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
def log_request_info(env, result, info, request = nil)
|
2024-07-02 20:38:49 -04:00
|
|
|
# We've got to skip this on error ... its just logging
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
data =
|
2023-01-09 07:10:19 -05:00
|
|
|
begin
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
self.class.get_data(env, result, info, request)
|
2024-07-02 20:38:49 -04:00
|
|
|
rescue StandardError => err
|
|
|
|
Discourse.warn_exception(err, message: "RequestTracker.get_data failed")
|
|
|
|
|
|
|
|
# This is super hard to find if in testing, we should still raise in this case.
|
|
|
|
raise err if Rails.env.test?
|
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
nil
|
2023-01-09 07:10:19 -05:00
|
|
|
end
|
2015-02-10 01:03:33 -05:00
|
|
|
|
|
|
|
if data
|
2016-10-27 01:50:56 -04:00
|
|
|
if result && (headers = result[1])
|
2016-10-27 03:08:01 -04:00
|
|
|
headers["X-Discourse-TrackView"] = "1" if data[:track_view]
|
2016-10-27 01:50:56 -04:00
|
|
|
end
|
2017-10-17 21:10:12 -04:00
|
|
|
|
|
|
|
if @@detailed_request_loggers
|
|
|
|
@@detailed_request_loggers.each { |logger| logger.call(env, data) }
|
|
|
|
end
|
|
|
|
|
2020-03-30 07:01:06 -04:00
|
|
|
log_later(data)
|
2015-02-05 00:08:52 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-08-09 03:47:44 -04:00
|
|
|
def self.populate_request_queue_seconds!(env)
|
|
|
|
if !env["REQUEST_QUEUE_SECONDS"]
|
|
|
|
if queue_start = env["HTTP_X_REQUEST_START"]
|
2020-06-19 10:17:24 -04:00
|
|
|
queue_start =
|
|
|
|
if queue_start.start_with?("t=")
|
|
|
|
queue_start.split("t=")[1].to_f
|
|
|
|
else
|
|
|
|
queue_start.to_f / 1000.0
|
|
|
|
end
|
2019-08-09 03:47:44 -04:00
|
|
|
queue_time = (Time.now.to_f - queue_start)
|
|
|
|
env["REQUEST_QUEUE_SECONDS"] = queue_time
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-11-28 00:47:20 -05:00
|
|
|
def call(env)
|
2017-12-11 01:21:00 -05:00
|
|
|
result = nil
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
info = nil
|
2023-08-01 22:46:37 -04:00
|
|
|
gc_stat_timing = nil
|
2018-04-17 04:05:51 -04:00
|
|
|
|
|
|
|
# doing this as early as possible so we have an
|
|
|
|
# accurate counter
|
2019-08-09 03:47:44 -04:00
|
|
|
::Middleware::RequestTracker.populate_request_queue_seconds!(env)
|
2018-04-17 04:05:51 -04:00
|
|
|
|
2018-03-15 17:10:45 -04:00
|
|
|
request = Rack::Request.new(env)
|
2017-12-11 01:21:00 -05:00
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
cookie = find_auth_cookie(env)
|
|
|
|
if error_details = rate_limit(request, cookie)
|
2024-01-15 14:54:50 -05:00
|
|
|
available_in, error_code, limit_on_id = error_details
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
message = <<~TEXT
|
2024-01-15 14:54:50 -05:00
|
|
|
Slow down, too many requests from this #{limit_on_id ? "user" : "IP address"}.
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
Please retry again in #{available_in} seconds.
|
|
|
|
Error code: #{error_code}.
|
|
|
|
TEXT
|
|
|
|
headers = {
|
2024-03-26 11:37:20 -04:00
|
|
|
"Content-Type" => "text/plain",
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
"Retry-After" => available_in.to_s,
|
|
|
|
"Discourse-Rate-Limit-Error-Code" => error_code,
|
|
|
|
}
|
2024-01-15 14:50:37 -05:00
|
|
|
if username = cookie&.[](:username)
|
|
|
|
headers["X-Discourse-Username"] = username
|
|
|
|
end
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
return 429, headers, [message]
|
2017-12-11 01:21:00 -05:00
|
|
|
end
|
2024-05-27 09:26:35 -04:00
|
|
|
|
|
|
|
if !cookie
|
|
|
|
if error_details = check_crawler_limits(env)
|
|
|
|
available_in, error_code = error_details
|
|
|
|
message = "Too many crawling requests. Error code: #{error_code}."
|
|
|
|
headers = {
|
|
|
|
"Content-Type" => "text/plain",
|
|
|
|
"Retry-After" => available_in.to_s,
|
|
|
|
"Discourse-Rate-Limit-Error-Code" => error_code,
|
|
|
|
}
|
|
|
|
return 429, headers, [message]
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-11-28 00:47:20 -05:00
|
|
|
env["discourse.request_tracker"] = self
|
2021-01-19 04:35:46 -05:00
|
|
|
|
2018-01-18 16:26:18 -05:00
|
|
|
MethodProfiler.start
|
2023-08-01 22:46:37 -04:00
|
|
|
|
|
|
|
if SiteSetting.instrument_gc_stat_per_request
|
|
|
|
gc_stat_timing = GCStatInstrumenter.instrument { result = @app.call(env) }
|
|
|
|
else
|
|
|
|
result = @app.call(env)
|
|
|
|
end
|
|
|
|
|
2018-01-18 16:26:18 -05:00
|
|
|
info = MethodProfiler.stop
|
2021-01-19 04:35:46 -05:00
|
|
|
|
2018-01-18 16:26:18 -05:00
|
|
|
# possibly transferred?
|
2018-01-19 01:51:04 -05:00
|
|
|
if info && (headers = result[1])
|
|
|
|
headers["X-Runtime"] = "%0.6f" % info[:total_duration]
|
2019-06-05 02:08:11 -04:00
|
|
|
|
|
|
|
if GlobalSetting.enable_performance_http_headers
|
|
|
|
if redis = info[:redis]
|
|
|
|
headers["X-Redis-Calls"] = redis[:calls].to_s
|
|
|
|
headers["X-Redis-Time"] = "%0.6f" % redis[:duration]
|
|
|
|
end
|
|
|
|
if sql = info[:sql]
|
|
|
|
headers["X-Sql-Calls"] = sql[:calls].to_s
|
|
|
|
headers["X-Sql-Time"] = "%0.6f" % sql[:duration]
|
|
|
|
end
|
|
|
|
if queue = env["REQUEST_QUEUE_SECONDS"]
|
|
|
|
headers["X-Queue-Time"] = "%0.6f" % queue
|
|
|
|
end
|
|
|
|
end
|
2018-01-18 16:26:18 -05:00
|
|
|
end
|
2018-03-06 00:49:31 -05:00
|
|
|
|
|
|
|
if env[Auth::DefaultCurrentUserProvider::BAD_TOKEN] && (headers = result[1])
|
|
|
|
headers["Discourse-Logged-Out"] = "1"
|
|
|
|
end
|
|
|
|
|
2017-11-28 00:47:20 -05:00
|
|
|
result
|
|
|
|
ensure
|
2018-03-05 23:20:39 -05:00
|
|
|
if (limiters = env["DISCOURSE_RATE_LIMITERS"]) && env["DISCOURSE_IS_ASSET_PATH"]
|
|
|
|
limiters.each(&:rollback!)
|
|
|
|
env["DISCOURSE_ASSET_RATE_LIMITERS"].each do |limiter|
|
|
|
|
begin
|
|
|
|
limiter.performed!
|
|
|
|
rescue RateLimiter::LimitExceeded
|
|
|
|
# skip
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
2023-08-01 22:46:37 -04:00
|
|
|
|
|
|
|
if !env["discourse.request_tracker.skip"]
|
|
|
|
info.merge!(gc_stat_timing) if gc_stat_timing
|
|
|
|
log_request_info(env, result, info, request)
|
|
|
|
end
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
def log_later(data)
|
|
|
|
Scheduler::Defer.later("Track view") do
|
2024-12-10 21:12:58 -05:00
|
|
|
begin
|
|
|
|
self.class.log_request(data) unless Discourse.pg_readonly_mode?
|
|
|
|
rescue ActiveRecord::ReadOnlyError
|
|
|
|
# Just noop if ActiveRecord is preventing writes
|
|
|
|
end
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def find_auth_cookie(env)
|
|
|
|
min_allowed_timestamp = Time.now.to_i - (UserAuthToken::ROTATE_TIME_MINS + 1) * 60
|
|
|
|
cookie = Auth::DefaultCurrentUserProvider.find_v1_auth_cookie(env)
|
|
|
|
cookie if cookie && cookie[:issued_at] >= min_allowed_timestamp
|
2017-11-28 00:47:20 -05:00
|
|
|
end
|
|
|
|
|
2018-01-07 16:39:17 -05:00
|
|
|
def is_private_ip?(ip)
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
ip = IPAddr.new(ip)
|
2021-03-21 23:56:32 -04:00
|
|
|
!!(ip && (ip.private? || ip.loopback?))
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
rescue IPAddr::AddressFamilyError, IPAddr::InvalidAddressError
|
|
|
|
false
|
2018-01-07 16:39:17 -05:00
|
|
|
end
|
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
def rate_limit(request, cookie)
|
|
|
|
warn =
|
|
|
|
GlobalSetting.max_reqs_per_ip_mode == "warn" ||
|
|
|
|
GlobalSetting.max_reqs_per_ip_mode == "warn+block"
|
|
|
|
block =
|
|
|
|
GlobalSetting.max_reqs_per_ip_mode == "block" ||
|
2018-01-21 21:18:30 -05:00
|
|
|
GlobalSetting.max_reqs_per_ip_mode == "warn+block"
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
|
|
|
|
return if !block && !warn
|
|
|
|
|
|
|
|
ip = request.ip
|
|
|
|
|
|
|
|
if !GlobalSetting.max_reqs_rate_limit_on_private
|
|
|
|
return if is_private_ip?(ip)
|
|
|
|
end
|
|
|
|
|
|
|
|
return if @@ip_skipper&.call(ip)
|
|
|
|
return if STATIC_IP_SKIPPER&.any? { |entry| entry.include?(ip) }
|
|
|
|
|
|
|
|
ip_or_id = ip
|
|
|
|
limit_on_id = false
|
|
|
|
if cookie && cookie[:user_id] && cookie[:trust_level] &&
|
|
|
|
cookie[:trust_level] >= GlobalSetting.skip_per_ip_rate_limit_trust_level
|
|
|
|
ip_or_id = cookie[:user_id]
|
|
|
|
limit_on_id = true
|
|
|
|
end
|
|
|
|
|
|
|
|
limiter10 =
|
|
|
|
RateLimiter.new(
|
|
|
|
nil,
|
2024-01-15 14:54:50 -05:00
|
|
|
"global_limit_10_#{ip_or_id}",
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
GlobalSetting.max_reqs_per_ip_per_10_seconds,
|
|
|
|
10,
|
|
|
|
global: !limit_on_id,
|
|
|
|
aggressive: true,
|
|
|
|
error_code: limit_on_id ? "id_10_secs_limit" : "ip_10_secs_limit",
|
2017-12-11 01:21:00 -05:00
|
|
|
)
|
2023-01-09 07:10:19 -05:00
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
limiter60 =
|
|
|
|
RateLimiter.new(
|
|
|
|
nil,
|
2024-01-15 14:54:50 -05:00
|
|
|
"global_limit_60_#{ip_or_id}",
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
GlobalSetting.max_reqs_per_ip_per_minute,
|
|
|
|
60,
|
|
|
|
global: !limit_on_id,
|
|
|
|
error_code: limit_on_id ? "id_60_secs_limit" : "ip_60_secs_limit",
|
|
|
|
aggressive: true,
|
|
|
|
)
|
2023-01-09 07:10:19 -05:00
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
limiter_assets10 =
|
|
|
|
RateLimiter.new(
|
|
|
|
nil,
|
2024-01-15 14:54:50 -05:00
|
|
|
"global_limit_10_assets_#{ip_or_id}",
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
GlobalSetting.max_asset_reqs_per_ip_per_10_seconds,
|
|
|
|
10,
|
|
|
|
error_code: limit_on_id ? "id_assets_10_secs_limit" : "ip_assets_10_secs_limit",
|
|
|
|
global: !limit_on_id,
|
|
|
|
)
|
2023-01-09 07:10:19 -05:00
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
request.env["DISCOURSE_RATE_LIMITERS"] = [limiter10, limiter60]
|
|
|
|
request.env["DISCOURSE_ASSET_RATE_LIMITERS"] = [limiter_assets10]
|
2018-03-05 23:20:39 -05:00
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
if !limiter_assets10.can_perform?
|
|
|
|
if warn
|
2024-01-15 14:54:50 -05:00
|
|
|
limited_on = limit_on_id ? "user_id" : "ip"
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
Discourse.warn(
|
2024-01-15 14:54:50 -05:00
|
|
|
"Global asset rate limit exceeded for #{limited_on}: #{ip}: 10 second rate limit",
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
uri: request.env["REQUEST_URI"],
|
|
|
|
)
|
2018-03-05 23:20:39 -05:00
|
|
|
end
|
|
|
|
|
2024-01-15 14:54:50 -05:00
|
|
|
if block
|
|
|
|
return [
|
|
|
|
limiter_assets10.seconds_to_wait(Time.now.to_i),
|
|
|
|
limiter_assets10.error_code,
|
|
|
|
limit_on_id
|
|
|
|
]
|
|
|
|
end
|
2017-12-11 01:21:00 -05:00
|
|
|
end
|
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
begin
|
|
|
|
type = 10
|
|
|
|
limiter10.performed!
|
|
|
|
|
|
|
|
type = 60
|
|
|
|
limiter60.performed!
|
|
|
|
|
|
|
|
nil
|
|
|
|
rescue RateLimiter::LimitExceeded => e
|
|
|
|
if warn
|
2024-01-15 14:54:50 -05:00
|
|
|
limited_on = limit_on_id ? "user_id" : "ip"
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
Discourse.warn(
|
2024-01-15 14:54:50 -05:00
|
|
|
"Global rate limit exceeded for #{limited_on}: #{ip}: #{type} second rate limit",
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
uri: request.env["REQUEST_URI"],
|
|
|
|
)
|
|
|
|
end
|
|
|
|
if block
|
2024-01-15 14:54:50 -05:00
|
|
|
[e.available_in, e.error_code, limit_on_id]
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
else
|
|
|
|
nil
|
2020-03-30 07:01:06 -04:00
|
|
|
end
|
2015-09-16 21:06:21 -04:00
|
|
|
end
|
|
|
|
end
|
2024-05-27 09:26:35 -04:00
|
|
|
|
|
|
|
def check_crawler_limits(env)
|
|
|
|
slow_down_agents = SiteSetting.slow_down_crawler_user_agents
|
|
|
|
return if slow_down_agents.blank?
|
|
|
|
|
2024-06-11 06:51:20 -04:00
|
|
|
user_agent = HttpUserAgentEncoder.ensure_utf8(env["HTTP_USER_AGENT"])&.downcase
|
2024-05-27 09:26:35 -04:00
|
|
|
return if user_agent.blank?
|
|
|
|
|
|
|
|
return if !CrawlerDetection.crawler?(user_agent)
|
|
|
|
|
|
|
|
slow_down_agents
|
|
|
|
.downcase
|
|
|
|
.split("|")
|
|
|
|
.each do |crawler|
|
|
|
|
if user_agent.include?(crawler)
|
|
|
|
key = "#{crawler}_crawler_rate_limit"
|
|
|
|
limiter =
|
|
|
|
RateLimiter.new(nil, key, 1, SiteSetting.slow_down_crawler_rate, error_code: key)
|
|
|
|
limiter.performed!
|
|
|
|
break
|
|
|
|
end
|
|
|
|
end
|
|
|
|
nil
|
|
|
|
rescue RateLimiter::LimitExceeded => e
|
|
|
|
[e.available_in, e.error_code]
|
|
|
|
end
|
2015-02-05 00:08:52 -05:00
|
|
|
end
|