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

app/controllers/master/api/providers_controller.rb

app/lib/signup/account_manager.rb

jlledom · 2026-03-11T17:28:16Z

lib/developer_portal/app/controllers/developer_portal/admin/account/users_controller.rb

  def update_resource(user, attributes)
    attributes.each do |attrs|
-      user.attributes = filter_readonly_params(attrs, User)
+      user.attributes = filter_readonly_params(attrs, User).permit!


All permitted here? is that expected?

Not good 😅 I guess it was some temporary thing, I'll need to fix it.

Fixed in d8e75bc

jlledom · 2026-03-11T17:32:12Z

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

Maybe we should list permitted attributes here instead of permitting everything.

Yeah... this didn't break after removing the attr_accessible, so I missed it, I guess.

Fixed implementation: fe5852b

I think I removed the update_resource method from that controller anyway!

Yes, great, it was just an example of which parameters were supposed to be permitted.

jlledom · 2026-03-11T17:38:34Z

app/lib/authentication/strategy/oauth2.rb

      class CreateInvitedUser < Procedure

        def call
          user = invitation.make_user(user_data.to_hash)


Where is user_data permitted?

So, honestly, I didn't dig too deep into the OAuth flows, but in general user_data is some data that is returned from the OAuth server, when authenticated via a third-party, see https://github.com/3scale/porta/blob/master/app/lib/three_scale/oauth2/user_data.rb#L8-L20 for its possible fields.

In this case specifically, .to_hash is applied, so the data is reduced to a hash with two fields - :username and :email. As it's a plain hash (not ActionController::Params), there is no need to permit.

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

app/controllers/admin/api/accounts_controller.rb

+    @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 🤔

Co-authored-by: Daria Mayorova <mayorova@users.noreply.github.com>

PaymentDetail

… strong parameters

jlledom added 4 commits March 10, 2026 12:44

Remove inherited_resources gem

5a1424b

Remove inherited_resources cancancan hack

352842c

Adapt controllers

afb5629

Fix tests

ddc9621

jlledom reviewed Mar 11, 2026

View reviewed changes

Better strong params in users controllers

a51a42c

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 4 times, most recently from 070a9e0 to d8e75bc Compare March 13, 2026 18:40

jlledom and others added 2 commits March 16, 2026 09:31

Apply suggestions from code review

3a712dc

Co-authored-by: Daria Mayorova <mayorova@users.noreply.github.com>

Fix empty member_permission_service_ids being ignored

958fa53

mayorova force-pushed the strong-params-part2 branch from 6887355 to c7bf8ef Compare March 16, 2026 12:57

jlledom and others added 6 commits March 16, 2026 14:58

Apply suggestions on controllers

847fbe9

Remove update_resource

02994a8

Fix users_controller test suite

a73056d

Add test suite for dev portal user controller

ccdf244

Apply review suggestions

1f10008

Apply suggestions from code review

1b2eeb2

Co-authored-by: Daria Mayorova <mayorova@users.noreply.github.com>

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

jlledom and others added 7 commits March 17, 2026 17:21

Update to responders 3.2.0

6bd96d4

Migrate to strong parameters for usage limits

7365128

Remove attr_accessible for application_key

2c00f88

Remove attr_accessible for referrer_filter

9160740

Migrate access tokens controller to strong params

9973aeb

Remove attr_accessible for line_item

03d5810

Migrate invoice to strong parameters

f330837

mayorova added 12 commits March 17, 2026 18:14

Migrate CMS groups to strong params

d6bd74a

Remove attr_accessible in CMS::GroupSection

9a708f8

Remove attr_accessible in RedhatCustomerPortal

b8e54b8

Remove attr_accessible in BackendEvent

d33ceb8

Remove attr_accessible in Topic, Post and CMS::Permission

e3c6dce

Remove protected attributes dependency in SSOToken

d6c4529

Remove attr_accessible from Partner

305e513

Remove attr_accessible from Onboarding

c0c2aaf

Remove attr_accessible in ServiceDiscoveryProvider

6213274

Migrate pricing rules controller to strong parameters

c241503

Remove attr_protected in PlanMetric

2c43bba

Strong parameters for plan features

3d84d08

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 added 6 commits March 17, 2026 23:19

Remove attr_protected in Alert and FieldsDefinition

9185b6c

Remove attr_protected from forum-related models

39dc6c3

Remove attr_protected from BillingStrategy, PaymentTransaction and

5c58f83

PaymentDetail

Remove attr_protected in multiple models

f5b0bb4

Remove attr_protected for Metric and Plan

45f4cac

Migrate settings controllers to strong parameters

6c69623

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 2 times, most recently from df4ba51 to 498f50b Compare March 18, 2026 17:34

mayorova added 3 commits March 18, 2026 18:47

Migrate User model and controllers to strong parameters

5c0d9a5

Migrate Account model, account and signup controllers and services to…

48251bb

… strong parameters

Migrate application controllers to strong parameters

706cacb

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

mayorova force-pushed the strong-params-part1 branch 2 times, most recently from bf3524b to a08b299 Compare March 18, 2026 23:54

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mayorova commented Mar 11, 2026 •

edited

Loading