discourse/spec/support/helpers.rb

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

238 lines
6.8 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
GIT_INITIAL_BRANCH_SUPPORTED =
Gem::Version.new(`git --version`.match(/[\d\.]+/)[0]) >= Gem::Version.new("2.28.0")
2013-09-05 07:22:15 -04:00
module Helpers
2016-12-12 20:59:38 -05:00
extend ActiveSupport::Concern
2013-09-05 07:22:15 -04:00
def self.next_seq
@next_seq = (@next_seq || 0) + 1
end
def log_in(fabricator = nil)
user = Fabricate(fabricator || :user)
log_in_user(user)
user
end
def log_in_user(user)
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_jar = ActionDispatch::Request.new(request.env).cookie_jar
provider = Discourse.current_user_provider.new(request.env)
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
provider.log_on_user(user, session, cookie_jar)
provider
end
def log_out_user(provider)
provider.log_off_user(session, cookies)
2013-09-05 07:22:15 -04:00
end
def fixture_file(filename)
return "" if filename.blank?
file_path = File.expand_path(Rails.root + "spec/fixtures/" + filename)
File.read(file_path)
end
def build(*args)
Fabricate.build(*args)
end
def create_topic(args = {})
args[:title] ||= "This is my title #{Helpers.next_seq}"
user = args.delete(:user)
if !user
user = Fabricate(:user)
Group.refresh_automatic_groups!
end
2013-09-05 07:22:15 -04:00
guardian = Guardian.new(user)
args[:category] = args[:category].id if args[:category].is_a?(Category)
2013-09-05 07:22:15 -04:00
TopicCreator.create(user, guardian, args)
end
def create_post(args = {})
# Pretty much all the tests with `create_post` will fail without this
# since allow_uncategorized_topics is now false by default
SiteSetting.allow_uncategorized_topics = true unless args[:allow_uncategorized_topics] == false
2013-09-05 07:22:15 -04:00
args[:title] ||= "This is my title #{Helpers.next_seq}"
args[:raw] ||= "This is the raw body of my post, it is cool #{Helpers.next_seq}"
args[:topic_id] = args[:topic].id if args[:topic]
automated_group_refresh_required = args[:user].blank?
2013-09-05 07:22:15 -04:00
user = args.delete(:user) || Fabricate(:user)
Group.refresh_automatic_groups! if automated_group_refresh_required
args[:category] = args[:category].id if args[:category].is_a?(Category)
creator = PostCreator.new(user, args)
post = creator.create
raise StandardError.new(creator.errors.full_messages.join(" ")) if creator.errors.present?
post
2013-09-05 07:22:15 -04:00
end
def stub_guardian(user)
guardian = Guardian.new(user)
yield(guardian) if block_given?
Guardian.stubs(new: guardian).with(user, anything)
end
2014-11-11 18:27:34 -05:00
def wait_for(on_fail: nil, timeout: 1, &blk)
2014-11-11 18:27:34 -05:00
i = 0
result = false
while !result && i < timeout * 1000
2014-11-11 18:27:34 -05:00
result = blk.call
i += 1
sleep 0.001
end
2017-08-23 10:41:47 -04:00
on_fail&.call
expect(result).to eq(true)
2014-11-11 18:27:34 -05:00
end
def email(email_name)
fixture_file("emails/#{email_name}.eml")
end
def create_staff_only_tags(tag_names)
create_limited_tags("Staff Tags", Group::AUTO_GROUPS[:staff], tag_names)
end
def create_limited_tags(tag_group_name, group_id, tag_names)
tag_group = Fabricate(:tag_group, name: tag_group_name)
TagGroupPermission.where(
tag_group: tag_group,
group_id: Group::AUTO_GROUPS[:everyone],
permission_type: TagGroupPermission.permission_types[:full],
).update(permission_type: TagGroupPermission.permission_types[:readonly])
TagGroupPermission.create!(
tag_group: tag_group,
group_id: group_id,
permission_type: TagGroupPermission.permission_types[:full],
)
tag_names.each do |name|
tag_group.tags << (Tag.where(name: name).first || Fabricate(:tag, name: name))
end
end
def create_hidden_tags(tag_names)
tag_group = Fabricate(:tag_group, name: "Hidden Tags", permissions: { staff: :full })
tag_names.each do |name|
tag_group.tags << (Tag.where(name: name).first || Fabricate(:tag, name: name))
end
end
def sorted_tag_names(tag_records)
tag_records.map { |t| t.is_a?(String) ? t : t.name }.sort
end
def expect_same_tag_names(a, b)
expect(sorted_tag_names(a)).to eq(sorted_tag_names(b))
end
def capture_output(output_name)
if ENV["RAILS_ENABLE_TEST_STDOUT"]
yield
return
end
previous_output = output_name == :stdout ? $stdout : $stderr
io = StringIO.new
output_name == :stdout ? $stdout = io : $stderr = io
yield
io.string
ensure
output_name == :stdout ? $stdout = previous_output : $stderr = previous_output
end
def capture_stdout(&block)
capture_output(:stdout, &block)
end
def capture_stderr(&block)
capture_output(:stderr, &block)
end
def set_subfolder(new_root)
global_setting :relative_url_root, new_root
old_root = ActionController::Base.config.relative_url_root
ActionController::Base.config.relative_url_root = new_root
Rails.application.routes.stubs(:relative_url_root).returns(new_root)
before_next_spec { ActionController::Base.config.relative_url_root = old_root }
if RSpec.current_example.metadata[:type] == :system
Capybara.app.map("/") { run lambda { |env| [404, {}, [""]] } }
Capybara.app.map(new_root) { run Rails.application }
before_next_spec do
Capybara.app.map(new_root) { run lambda { |env| [404, {}, [""]] } }
Capybara.app.map("/") { run Rails.application }
end
end
end
def setup_git_repo(files)
repo_dir = Dir.mktmpdir
`cd #{repo_dir} && git init . #{"--initial-branch=main" if GIT_INITIAL_BRANCH_SUPPORTED}`
`cd #{repo_dir} && git config user.email 'someone@cool.com'`
`cd #{repo_dir} && git config user.name 'The Cool One'`
`cd #{repo_dir} && git config commit.gpgsign 'false'`
files.each do |name, data|
FileUtils.mkdir_p(Pathname.new("#{repo_dir}/#{name}").dirname)
File.write("#{repo_dir}/#{name}", data)
`cd #{repo_dir} && git add #{name}`
end
`cd #{repo_dir} && git commit -am 'first commit'`
repo_dir
end
FEATURE: Theme settings migrations (#24071) This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values. Example use cases for the theme settings migration system: 1. Renaming a theme setting. 2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting). 3. Altering the format of data stored in a theme setting. All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings. Usage: 1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`. 2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration. 3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received). 4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included. 5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme. 6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`. Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`: ```js // File name: 0001-rename-setting.js export default function migrate(settings) { if (settings.has("setting_with_old_name")) { settings.set("setting_with_new_name", settings.get("setting_with_old_name")); } return settings; } ``` Internal topic: t/109980
2023-11-02 01:10:15 -04:00
def add_to_git_repo(repo_dir, files)
files.each do |name, data|
FileUtils.mkdir_p(Pathname.new("#{repo_dir}/#{name}").dirname)
File.write("#{repo_dir}/#{name}", data)
`cd #{repo_dir} && git add #{name}`
end
`cd #{repo_dir} && git commit -am 'add #{files.size} files'`
repo_dir
end
def stub_const(target, const, value)
old = target.const_get(const)
target.send(:remove_const, const)
target.const_set(const, value)
yield
ensure
target.send(:remove_const, const)
target.const_set(const, old)
end
def track_sql_queries
queries = []
callback = ->(*, payload) do
queries << payload.fetch(:sql) unless %w[CACHE SCHEMA].include?(payload.fetch(:name))
end
ActiveSupport::Notifications.subscribed(callback, "sql.active_record") { yield }
queries
end
def stub_ip_lookup(stub_addr, ips)
Addrinfo
.stubs(:getaddrinfo)
.with { |addr, _| addr == stub_addr }
.returns(
ips.map { |ip| Addrinfo.new([IPAddr.new(ip).ipv6? ? "AF_INET6" : "AF_INET", 80, nil, ip]) },
)
end
def with_search_indexer_enabled
SearchIndexer.enable
yield
ensure
SearchIndexer.disable
end
2013-09-05 07:22:15 -04:00
end