THREESCALE-12434: Migrate from protected attributes to strong parameters - Part 2 by mayorova · Pull Request #4249 · 3scale/porta

mayorova · 2026-03-11T15:28:55Z

What this PR does / why we need it:

This is part 2 of the migration from protected attributes to strong parameters. See the first part in #4248

Protected attributes is an old Rails feature which was deprecated a long time ago. We were using protected_attributes_continued gem to keep it working, but now it's also discontinued and does not support Rails 7+, so it's a blocker for upgrading to Rails 7.2 for us.

This Part 2 handles the models that can have custom attributes through FieldsDefinitions - Account, User, Cinstance.

Which issue(s) this PR fixes

https://redhat.atlassian.net/browse/THREESCALE-12434

Verification steps

All tests should pass, and all features should work as before.

Special notes for your reviewer:

jlledom

Some comments come from the other PR. Also, I still see a lot of

mayorova · 2026-03-13T00:09:55Z

+    @account_params ||= begin
+      defined_fields_names = buyer_account.defined_fields_names
+      allowed_attrs = defined_fields_names - %w(billing_address) + %w(name)
+      nested_params = { extra_fields: buyer_account.defined_extra_fields_names }


So, this is different from other API controller, which have only plain parameters, i.e. not nested under extra_fields.
I only did this because there was an existing test in test/integration/admin/api/accounts_controller_test.rb which was passing extra params in this way:

params: update_params.merge(extra_fields: { my_field: 4 })

I also added a check that plain parameters would also work.

Now I'm not sure if other API controllers need to accept both ways too 🤔

qltysh · 2026-03-19T15:34:38Z

❌ 26 blocking issues (26 total)

Tool	Category	Rule	Count
rubocop	Style	Use 0o for octal literals.	12	❌
reek	Lint	Provider::Admin::AccountsController#update_account_params has approx 9 statements	3	❌
reek	Lint	DeveloperPortal::BaseController#filter_readonly_params refers to 'read_only_fields' more than self (maybe move it to another class?)	2	❌
rubocop	Lint	Prefer `response\.parsed\_body`.	2	❌
rubocop	Lint	Assignment Branch Condition size for `create` is too high. [<7, 31, 3> 31.92/20]	1	❌
brakeman	Vulnerability	Specify exact keys allowed for mass assignment instead of using `permit\!` which allows any keys.	1	❌
rubocop	Lint	Use `ActionDispatch::IntegrationTest` instead.	1	❌
rubocop	Lint	Use `find\_by\!` instead of dynamic `find\_by\_code\!`.	1	❌
rubocop	Style	Incorrect formatting, autoformat by running `qlty fmt`.	1	❌
rubocop	Style	Trailing whitespace detected.	1	❌
reek	Lint	ApplicationsControllerMethodsTest::TestController#params is a writable attribute	1	❌

@qltysh one-click actions:

Auto-fix formatting (qlty fmt && git push)

mayorova · 2026-06-02T21:06:07Z

-    application.unflattened_attributes = application_params
-    application.user_key = params[:user_key] if params[:user_key]
-    application.application_id = params[:application_id] if params[:application_id]
+    application.assign_attributes(application_params)


user_key and application_id used to be protected attributes. It is not needed to split their assignment anymore. Both are explicitly added to the permitted parameters.

mayorova · 2026-06-02T21:08:23Z

-  def application_attributes
-    current_account.fields.for(Cinstance) + %w|user_key application_id|
+    allowed_attrs = current_account.defined_fields_names_for(Cinstance) +
+                    %w[user_key application_id redirect_url first_traffic_at first_daily_traffic_at]


redirect_url first_traffic_at first_daily_traffic_at are part of the old current_account.fields.for(Cinstance)

mayorova · 2026-06-02T21:11:51Z

+  end
+
+  def account_params
+    allowed_attrs = current_account.defined_fields_names_for(Account) - %w[billing_address]


Setting billing_address as a plain value (e.g. a string) is not supported.
Not sure, however, if we need to add the complex handling like in app/controllers/admin/api/accounts_controller.rb

Was it possible before?

According to Claude, it accepted a hash before, so if we want to preserve old behavior, we must implement it like this:

def account_params allowed_attrs = current_account.defined_fields_names_for(Account) - %w[billing_address] nested = { annotations: {} } if current_account.defined_fields_names_for(Account).include?('billing_address') nested[:billing_address] = %i[name address1 address2 city country state zip phone] end params.permit(*allowed_attrs, **nested) end

However, I'm fine with removing billing address entirely from the signup controller unless we know a scenario where this would be required.

I made a test for signups controller in master (similar to the one for the account controller), and unfortunately, the same behavior is supported... both nested hash and individual fields work for setting billing address.
So, I'll have to add the same logic.

maybe admin/api/users_controller.rb as well? This is what Bob thinks

maybe admin/api/users_controller.rb as well? This is what Bob thinks

admin/api/users_controller.rb is for provider's users, so we don't need billing address there.

mayorova · 2026-06-02T21:14:15Z

-  def flat_params
-    super.except(:id)
+  def user_params
+    defined_fields_names = current_account.provider_account.defined_fields_names_for(User)


These endpoints are for managing the users of the provider account (current_account in this case), so we need to check the fields definitions configured on the provider's provider (aka master account), hence current_account.provider_account.

I wonder if it would be more understandable to have it as Account.master.defined_fields_names_for(User) in this case. But it is fine to stay, just a thought. I'm not sure which is better.

mayorova · 2026-06-02T21:15:29Z

-    super.except(:id)
+  def user_params
+    defined_fields_names = current_account.provider_account.defined_fields_names_for(User)
+    permission_attrs = [:member_permission_service_ids, { member_permission_service_ids: [], member_permission_ids: [] }]


member_permission_service_ids can be nil (meaning all services are enabled), or an array (including an empty array), so both plain and array-like parameters need to be permitted.

ideally that would be a code comment for future readers. Although I think we have tests for that so one will notice.

mayorova · 2026-06-02T21:22:35Z

+    defined_fields_names = current_account.provider_account.defined_fields_names_for(User)
+    permission_attrs = [:member_permission_service_ids, { member_permission_service_ids: [], member_permission_ids: [] }]
+    allowed_attrs = defined_fields_names + %w[password password_confirmation cas_identifier]
+    allowed_attrs += permission_attrs if provider_key.present? || current_user.admin?


Permission attributes were only restricted for admin users here:

attr_accessible :member_permission_service_ids, :member_permission_ids, as: %i[admin]

A bit worried about this, the security depends on we remembering to always add this check in all controllers that handle these attributes. Is this properly tested?

If we have to add such a check in controller, why not delegating this to cancancan like we do here?

porta/app/controllers/provider/admin/account/users_controller.rb

Lines 61 to 64 in 71e6ead

if can?(:update_role, @user)

allowed_attrs += [:role, { member_permission_ids: [] }]

allowed_attrs += [:member_permission_service_ids, { member_permission_service_ids: [] }] if current_account.provider_can_use?(:service_permissions)

end

I also thought about cancan, this role you found is really nice.

The issue though is this provider_key.present? which, if provider)key was used, results in no user being set thus cancan will reject the operation.

So it will be nice to have it but I would not require it for this PR.

On the other hand, previously provider_key auth was not handled, so not handling it in this PR will not be a regression.

An easy fix might be to set current_user to first admin when provider_key is used. But then this may require more investigation than necessary for this PR.

In summary, I'm ok with all options:

keep as is

use cancan and ignore provider_key

use cancan and alter provider_key auth to set an admin user (or whatever alternative solution we can come up with)

But we already have a ApiAuthentication::ByProviderKey module, I assume if the request came with a provider key, we already use it to get the proper user, and the user will have the proper cancancan permissions, so it should just work without worrying about how the user was authenticated.

I checked this. When we authenticate via :provider_key, current_user is not set at all, so we can't use cancancan here. In fact, there are a few calls to authorize! in some actions, but the method is overwritten to just check if we are logged in...

What I wonder is: are we implementing all these ugly workarounds in each API controller in order to accept provider keys?

This is what claude says:

● So there are three different strategies in play: 1. Override authorize! to skip cancancan when no user (the 4 controllers we found) 2. Guard with if current_user — services_controller, signups_controller, web_hooks_failures_controller, api_docs_services_controller — cancancan is simply not called for provider_key requests 3. Call authorize! unconditionally — access_tokens_controller, authentication_providers_controller, backend_apis_controller, backend_apis/base_controller, registry/policies_controller, services/backend_usages_controller — these would hit cancancan with a nil user and likely fail on provider_key auth 4. Creative workaround — application_plans_controller builds its own Ability from current_account.admins.first, sidestepping the nil user entirely

This project is gonna kill me.

This is what I told you :) that current_user is not set. But we can change the module to set first admin for example. Provider key means something like the provider root account. When you lost access to your admin for some reason, you can recover with the provider key.

I think that not so many controllers check user permissions. In all of them though, we would need special logic to handle provider_key auth. Again, a simple workaround might be setting current_user to the first admin in such case.

As this is not a regression though, I would suggest such improvements to be performed within another JIRA issue.

I understand you now. Yeah, I think setting current_user to the impersonation admin when using provider_key would probably work out of the box. But seems something to be done in a separate PR.

I don't quite understand what Claude is suggesting... But here are some points:

I think the implementation was already confusing in the first place. There are two places where attr_accessible is set for these fields:

in models/user.rb:
attr_accessible :member_permission_service_ids, :member_permission_ids, as: %i[admin]

in models/user/permissions.rb:
attr_accessible :member_permission_service_ids, :member_permission_ids, :allowed_sections, :allowed_service_ids

I don't really understand how this is expected to work based on the protected_attributes_continued documentation, Claude and Bob are also confused.

But according to the tests, this is what happens:

user.update_with_flattened_attributes(flat_params, as: current_user.try(:role))

Indeed, if provider_key is used, current_user would be nil, so, assign_attributes will be called with as: nil, and then, the role defaults to :default value.

Probably, because of the missing role in attr_accessible in permissions.rb, :default is actually considered the role that can update the fields due to this default.

So, with as: :admin and as: nil the update works, and with as: :member it doesn't apparently.

I ran the test 'set member permissions with provider key' on master, and the behavior is the same as in this branch. The tests 'set group permissions as an admin' and 'set group permissions as a member' also pass on both branches, so I think that effectively the behavior is the same.

There are really just two controllers where these fields can potentially be set: the API one (this), and the UI one (app/controllers/provider/admin/account/users_controller.rb). In the API one we need to handle the provider key explicitly, and in the UI one it is handled using can?, because there is always a valid current user.
So, I am not overly worried about:

the security depends on we remembering to always add this check in all controllers that handle these attributes

I am not expecting us to add more controllers for handling these fields.

Conclusion:

I think the current implementation achieves the same behavior as before, so I wouldn't complicate things any more.

Yeah, not in this PR. What I thought was that in case we already have or add in the future permissions checks in other controllers, it might be worth having a current_user set with provider_key auth as well.

mayorova · 2026-06-02T21:26:42Z

-    @account_params ||= params.require(:account).except(:user)
+    defined_builtin_fields_names = current_account.defined_builtin_fields_names_for(Account)
+    defined_extra_fields_names = current_account.defined_extra_fields_names_for(Account)
+    allowed_attrs = defined_builtin_fields_names - %w[billing_address country] + %w[country_id]


billing_address and country fields do not even appear in the form as editable:

for setting the country, there is a dropdown select with country_id as values

billing_address is showed, but greyed out (it can not be directly modified via UI)

The test 'update account, including optional built-in and custom fields' of test/integration/buyers/accounts_controller_test.rb verifies the behavior for these fields.

mayorova · 2026-06-02T21:29:54Z

+    defined_builtin_fields_names = current_account.defined_builtin_fields_names_for(Account)
+    defined_extra_fields_names = current_account.defined_extra_fields_names_for(Account)
+    allowed_attrs = defined_builtin_fields_names - %w[billing_address country] + %w[country_id]
+    params.require(:account).permit(*allowed_attrs, extra_fields: defined_extra_fields_names)


Here and in other UI controllers - custom parameters (invented by the user) are submitted inside extra_fields, e.g. account[extra_fields][something]=value.
Other parameters (default or not) are submitted as account's attributes, e.g. account[org_name]=ok or account[vat_rate]=30

mayorova · 2026-06-02T21:32:14Z

+  def permitted_user_params
+    fields_names = current_account.defined_fields_names_for(User)
+    extra_fields_names = current_account.defined_extra_fields_names_for(User)
+    user_params.permit(*fields_names, :password, :password_confirmation,


We do not need to add role to the list, because it is not assigned massively anyway due to a permission check:

user.role = user_params.fetch(:role, user.role) if can?(:update_role, user)

But maybe :role was being set in another line precisely because it was a protected attribute, not only because of the permission check. We could also use that permission check to decide whether we permit the attribute or not. The same we do in provider/admin/account/users_controller (see comment above). I don't have a strong opinion, though.

user_params.fetch(:role, user.role) makes it perhaps harder to handle it like in the other controllers... unless they handle the same problem already, that I don't remember spotting but I might have missed it :)

How about this? 2aec247

mayorova · 2026-06-03T08:08:03Z

  private

  def user_params
-    flat_params.merge({signup_type: :minimal})


This signup_type: :minimal was moved to signup_params method.

mayorova · 2026-06-03T08:12:17Z

    @user.validate_fields!

    @user.assign_attributes(user_params)
-    @user.role = user_params.fetch(:role, @user.role)


No need to set role explicitly, because it's not a protected attribute anymore.

mayorova · 2026-06-03T08:17:22Z

  before_action :ensure_signup_possible

  skip_before_action :login_required
-  skip_before_action :enable_analytics, only: :test


Removed because there is no :test action.

mayorova · 2026-06-03T08:19:23Z


  def signup_params
-    Signup::SignupParams.new(plans: [plan], user_attributes: user_params, account_attributes: account_params, validate_fields: true)
+    Signup::SignupParams.new(plans: [plan], user_attributes: user_params.merge(signup_type: :new_signup, username: :admin), account_attributes: account_params.merge(sample_data: true), validate_fields: true)


Moved signup_type: :new_signup, username: :admin here from user_params.

I am just trying to follow the same pattern everywhere - user_params, account_params etc. just permit the parameters, and we add any extra fields in another place (either signup_params, or in the .update call itself.

Same for sample_data: true)

mayorova · 2026-06-03T08:26:21Z


  def account_params
-    params.require(:account).except(:user).merge(sample_data: true)
+    allowed_attrs = master.defined_builtin_fields_names_for(Account) + %w[name subdomain self_subdomain]


This list (and the one for user params) was derived from checking how the signup form works: https://github.com/3scale/porta/blob/e80983fc2723d4281f688e4b3fdc2b3c5f251ccb/app/lib/fields/signup_form.rb

In any case, now this form is disabled by default both in on-premises and in SaaS:
#4242

mayorova · 2026-06-03T08:26:50Z

  def handle_cache_response
    expires_in 1.hour, public: true
-    fresh_when etag: default_params, last_modified: System::Application.config.boot_time
+    fresh_when etag: params.permit!.to_h, last_modified: System::Application.config.boot_time


Just maintaining the previous behavior.

mayorova · 2026-06-03T08:28:57Z

    self.class.internal_fields
  end

-  def special_fields


Removing all things related to special fields. They were only used for fetching password password_confirmation attributes or user, but it's much cleaner IMO to just include them in the controller's permitted params list directly.
Especially, as some controllers just accept password, and some others - both password and password_confirmation.

mayorova · 2026-06-03T08:29:43Z

+
  def plan_id
-    @plan_id ||= params.require(:cinstance).permit(:plan_id).tap { |plan_params| plan_params.require(:plan_id) }[:plan_id]
+    @plan_id ||= cinstance_params.permit(:plan_id).require(:plan_id)


This simplified form seems to be doing the same as the original.

mayorova · 2026-06-03T08:30:18Z

    sso_attributes.all? { |_key, value| value.present? }
  end

-  def create_sso_authorization


This method was not used anywhere.

mayorova · 2026-06-03T09:05:38Z

    end

+    def account_params
+      allowed_attrs = site_account.defined_fields_names_for(Account) - %w[country vat_rate] + %w[country_id]


Country is set via a dropdown select, where the values are country_id, so country (the actual name of the builtin field) is removed.

vat_rate can not be updated by the developer by design.

akostadinov · 2026-06-03T19:36:45Z

+
+  def user_params
+    defined_fields_names = current_account.defined_fields_names_for(User)
+    params.permit(*defined_fields_names, :password)


same question about password_confirmation, should we allow in APIs or not. But it is fine as is.

akostadinov

Awesome stuff! I added some questions but I suspect they are not very valid 👼

jlledom · 2026-06-03T15:30:36Z

+    if defined_fields_names.include?('billing_address')
+      allowed_attrs += %w[billing_address_name billing_address_address1 billing_address_address2 billing_address_city
+                          billing_address_country billing_address_state billing_address_zip billing_address_phone]
+      nested_params[:billing_address] = %i[name address1 address2 city country state zip phone]


Why not same as above?

Suggested change

nested_params[:billing_address] = %i[name address1 address2 city country state zip phone]

nested_params[:billing_address] = %w[name address1 address2 city country state zip phone]

Not sure to be honest... But agree to make it more consistent.

jlledom · 2026-06-03T15:53:40Z

+  def contract_params
+    allowed_attrs = current_account.defined_fields_names_for(Cinstance) +
+                    %w[user_key application_id redirect_url first_traffic_at first_daily_traffic_at]
+    params.permit(*allowed_attrs)


Why adding ["user_key", "application_id"] if those were not permitted before?

jlledom · 2026-06-04T07:17:26Z

+  end
+
+  def account_params
+    allowed_attrs = current_account.defined_fields_names_for(Account) - %w[billing_address]


According to Claude, it accepted a hash before, so if we want to preserve old behavior, we must implement it like this:

def account_params allowed_attrs = current_account.defined_fields_names_for(Account) - %w[billing_address] nested = { annotations: {} } if current_account.defined_fields_names_for(Account).include?('billing_address') nested[:billing_address] = %i[name address1 address2 city country state zip phone] end params.permit(*allowed_attrs, **nested) end

However, I'm fine with removing billing address entirely from the signup controller unless we know a scenario where this would be required.

jlledom · 2026-06-04T07:41:39Z

+    defined_fields_names = current_account.provider_account.defined_fields_names_for(User)
+    permission_attrs = [:member_permission_service_ids, { member_permission_service_ids: [], member_permission_ids: [] }]
+    allowed_attrs = defined_fields_names + %w[password password_confirmation cas_identifier]
+    allowed_attrs += permission_attrs if provider_key.present? || current_user.admin?


A bit worried about this, the security depends on we remembering to always add this check in all controllers that handle these attributes. Is this properly tested?

If we have to add such a check in controller, why not delegating this to cancancan like we do here?

porta/app/controllers/provider/admin/account/users_controller.rb

Lines 61 to 64 in 71e6ead

if can?(:update_role, @user)

allowed_attrs += [:role, { member_permission_ids: [] }]

allowed_attrs += [:member_permission_service_ids, { member_permission_service_ids: [] }] if current_account.provider_can_use?(:service_permissions)

end

jlledom · 2026-06-04T07:51:37Z

+  def permitted_user_params
+    fields_names = current_account.defined_fields_names_for(User)
+    extra_fields_names = current_account.defined_extra_fields_names_for(User)
+    user_params.permit(*fields_names, :password, :password_confirmation,


But maybe :role was being set in another line precisely because it was a protected attribute, not only because of the permission check. We could also use that permission check to decide whether we permit the attribute or not. The same we do in provider/admin/account/users_controller (see comment above). I don't have a strong opinion, though.

jlledom · 2026-06-04T08:23:28Z

-    # This is just a sanity guard added when splitting invitation
-    # controllers. Remove when SURE.
-    raise 'Developer invitation used and worked on provider side!' unless @user.account.provider?


Are you SURE?

Pretty SURE, yes 😬

mayorova · 2026-06-05T18:58:22Z

@akostadinov @jlledom hopefully, I addressed your concerns in 3929c52

jlledom reviewed Mar 11, 2026

View reviewed changes

mayorova force-pushed the strong-params-part2 branch 2 times, most recently from 38e277c to db25ecf Compare March 13, 2026 00:03

mayorova commented Mar 13, 2026

View reviewed changes

mayorova force-pushed the strong-params-part2 branch 6 times, most recently from a676b21 to 8b5a6de Compare March 17, 2026 15:36

mayorova mentioned this pull request Mar 17, 2026

[WIP] [PoC] Migrate from protected attributes to strong parameters #4238

Closed

mayorova changed the base branch from master to strong-params-part1 March 17, 2026 17:19

mayorova changed the title ~~Strong params part2~~ THREESCALE-12434: Migrate from protected attributes to strong parameters - Part 2 Mar 17, 2026

mayorova force-pushed the strong-params-part1 branch from 0b8ead4 to 6c69623 Compare March 18, 2026 15:35

mayorova force-pushed the strong-params-part2 branch 3 times, most recently from 498f50b to 706cacb Compare March 18, 2026 17:47

mayorova force-pushed the strong-params-part1 branch 3 times, most recently from a08b299 to d3304a9 Compare March 19, 2026 12:26

mayorova force-pushed the strong-params-part2 branch 2 times, most recently from e2771a2 to 1abbc5c Compare March 19, 2026 15:32

mayorova marked this pull request as ready for review March 19, 2026 15:34

mayorova mentioned this pull request Mar 19, 2026

THREESCALE-12434: Migrate from protected attributes to strong parameters - Part 3 #4255

Open

mayorova force-pushed the strong-params-part2 branch 2 times, most recently from 279e452 to 7981703 Compare March 25, 2026 09:14

jlledom approved these changes Mar 30, 2026

View reviewed changes

mayorova force-pushed the strong-params-part1 branch 2 times, most recently from 4b5523f to 5f946c2 Compare April 20, 2026 10:07

mayorova commented Jun 2, 2026

View reviewed changes

mayorova commented Jun 3, 2026

View reviewed changes

akostadinov reviewed Jun 3, 2026

View reviewed changes

Comment thread app/controllers/admin/api/signups_controller.rb Outdated

akostadinov reviewed Jun 3, 2026

View reviewed changes

Comment thread app/controllers/provider/signups_controller.rb

akostadinov approved these changes Jun 3, 2026

View reviewed changes

jlledom approved these changes Jun 4, 2026

View reviewed changes

mayorova commented Jun 5, 2026

View reviewed changes

Comment thread lib/developer_portal/app/controllers/developer_portal/signup_controller.rb Outdated

mayorova commented Jun 5, 2026

View reviewed changes

Comment thread app/controllers/provider/admin/user/personal_details_controller.rb

mayorova commented Jun 5, 2026

View reviewed changes

Comment thread app/controllers/buyers/accounts_controller.rb

mayorova added 2 commits June 5, 2026 19:10

Apply fixes after peer review

3929c52

Refactor handling 'role' parameter in Buyers::UsersController

2aec247

	if can?(:update_role, @user)
	allowed_attrs += [:role, { member_permission_ids: [] }]
	allowed_attrs += [:member_permission_service_ids, { member_permission_service_ids: [] }] if current_account.provider_can_use?(:service_permissions)
	end

	nested_params[:billing_address] = %i[name address1 address2 city country state zip phone]
	nested_params[:billing_address] = %w[name address1 address2 city country state zip phone]

Conversation

mayorova commented Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jlledom left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

qltysh Bot commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mayorova Jun 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mayorova Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

mayorova commented Mar 11, 2026 •

edited

Loading

qltysh Bot commented Mar 19, 2026 •

edited

Loading

mayorova Jun 2, 2026 •

edited

Loading

mayorova Jun 3, 2026 •

edited

Loading