Rule support: confirmed validation rule ignored

[luckcolors]

• [x] I confirm that I have read and attempted the tips in the Troubleshooting Guide.

What happened? I'm using scribe to generate post requests for my app. It seems that when the confirmed validator gets used it's ignored as it's un supported, according to this list here. https://scribe.knuckles.wtf/laravel/documenting/query-body-parameters#supported-validation-rules).

The behaviour of confirmed is to simply add a copy of the field it's specified on with _confirmed appended to it in order to validate equality with the original one. [https://laravel.com/docs/9.x/validation#rule-confirmed]https://laravel.com/docs/9.x/validation#rule-confirmed

So what happens is that given the following example of a register post request:

    public function rules(): array {
        return [
            'name' =>  ['required', 'string'],
            'email' =>   ['required', 'string', 'email'],
            'password' =>  ['required', 'confirmed', Password::min(12)->mixedCase()]
            ];
      }

    public function bodyParameters(): array {
        return [
            'name' => [
                'example' => 'Hello'
            ],
            'email' => [
                'example' => 'hello@world'
            ],
            'password' => [
                'example' => 'passwordpassword'
            ];
      }

Generated scribe request:

{
  "name": "Hello",
  "email": "hello@world",
  "password": "passwordpassword",
}

The generated request lacks the "password_confirmation" field.

My environment:

• PHP version (from php -v): v8.1.4
• Framework (Laravel/Lumen): v9.0
• Laravel/Lumen version (from composer show laravel/framework or composer show laravel/lumen-framework): v9.27.0
• Scribe version (from composer show knuckleswtf/scribe): v3.37.1

My Scribe config (minus the comments): defaults

[shalvah]

The behaviour of confirmed is to simply add a copy of the field

That's the problem. It's adding another field. The rules we support currently just add information about an existing field. We could theoretically support this in future, but not any time soon.

Out of curiosity, what are you using a password confirmation field in an API for? That seems like something better suited for front-ends, where the password is masked (and even there, it's an anti-pattern). In an API, you're just having someone write duplicate code.

[luckcolors]

The reason was so the client can just directly map a form into the request without doing extra work.

But yeah i suppose i could do less with the validator or extra field.

Up to you if you think this should be implemented at some point.

Thanks for the quick reply. 😄