POST /api/v1/apps accepts a scopes array but sets scopes to default scopes

[ThisIsMissEm]

Steps to reproduce the problem

I was working on additional test cases for spec/requests/api/v1/apps_spec.rb, and added the following:

  context 'with scopes as an array' do
      let(:scopes) { %w(read write follow) }

      it 'creates an OAuth App with the supplied scopes' do
        subject

        expect(response).to have_http_status(200)

        app = Doorkeeper::Application.find_by(name: client_name)

        expect(app).to be_present
        expect(app.scopes.to_s).to eq 'read write follow'

        body = body_as_json

        expect(body[:scopes]).to eq scopes
      end
    end

This test case currently fails, as scopes gets set to read which is the default scopes.

1) Apps POST /api/v1/apps with scopes as an array creates an OAuth App with the default scope
     Failure/Error: expect(app.scopes.to_s).to eq 'read write follow'
     
       expected: "read write follow"
            got: "read"
     
       (compared using ==)
     # ./spec/requests/api/v1/apps_spec.rb:68:in `block (4 levels) in <top (required)>'

Expected behaviour

Either an array should work, or it should throw a 422 unprocessible entity error

Actual behaviour

falls back to the default scopes configured for doorkeeper

Detailed description

It's arguable which way this should go: scopes is already "non-standard" if compared to the OAuth 2.0 Dynamic Client Registration spec (https://www.rfc-editor.org/rfc/rfc7591.html#section-2), which expects a scope property with the scopes being space separated.

Currently scopes of "read write follow" works as expected, however if scopes is an array, then the default scopes configured on doorkeeper are returned as the application's scopes.

I think it should probably error, and we should also move towards using scope instead of scopes.

Mastodon instance

No response

Mastodon version

v4.3 / main — 9e26001

Technical details

If this is happening on your own Mastodon server, please fill out those:

• Ruby version: v3.3.1
• Node.js version: n/a

[ThisIsMissEm]

I think I know what's happening here: it's due to rails parameters. As we're just doing params.permit(:scopes) it only allows through a non-array/non-object parameter. It doesn't actually fail if the parameter is supplied but is the wrong type (array instead of string), it just returns nil for that parameter, so we end up with the default value.

A stricter validation of the parameters here would result in a 422 unprocessible entity error, since we could assert that only a string is acceptable.