required readOnly fields are required in request body when they shouldn't be

[sampoh0523]

Description

When an API object has a field that is required but has readOnly: true, a request containing an object without that field fails to validate.

OpenAPI spec says:

You can use the readOnly and writeOnly keywords to mark specific properties as read-only or write-only. This is useful, for example, when GET returns more properties than used in POST – you can use the same schema in both GET and POST and mark the extra properties as readOnly. readOnly properties are included in responses but not in requests, [...]

If a readOnly or writeOnly property is included in the required list, required affects just the relevant scope – responses only or requests only. That is, read-only required properties apply to responses only, [...]

This is a regression from Connexion 2.x.

Expected behaviour

Object validates successfully.

Actual behaviour

Object fails to validate, because it is missing a read-only field:

ERROR:connexion.validators.json:Validation error: 'objectId' is a required property
ERROR:connexion.middleware.exceptions:BadRequestProblem(status_code=400, detail="'objectId' is a required property")

Presumably Connexion 3.x fails to use jsonschema validation properly here.

Steps to reproduce

1. Use the openapi.yaml and testcontroller.py from below
2. Start with connexion run openapi.yaml --stub
3. Attempt to do the following request: PUT .../objects/45d2847a-ed55-440a-bfa7-5e759d0d671f, with body

{
    "name": "abc"
}

Minimal example:

openapi.yaml

openapi: 3.0.3
info:
  title: test
  version: '1.0'
paths:
  '/objects/{objectId}':
    parameters:
      - schema:
          type: string
          format: uuid
        name: objectId
        in: path
        required: true
    put:
      summary: Create or update object
      operationId: object_put
      x-openapi-router-controller: testcontroller
      responses:
        '200':
          description: OK - Object updated
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Object'
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Object'
components:
  schemas:
    Object:
      title: BaseObject
      type: object
      properties:
        objectId:
          type: string
          format: uuid
          readOnly: true
        name:
          type: string
      required:
      - objectId
      - name

testcontroller.py

from connexion import FlaskApp, request

app = FlaskApp(__name__)


def object_put(objectId, body):
    return {"objectId": objectId, **body}


app.add_api("openapi.yaml")

Additional info:

Output of the commands:

• python --version
  • Python 3.11.3
• pip show connexion | grep "^Version\:"
  • Version: 3.0.6

[RobbeSneyders]

Thanks for the report @sampoh0523.

Seems like we need to reinclude this validator. Do you mind submitting a PR for this?

[whoseoyster]

@RobbeSneyders I'm surprised people are able to use connexion 3 without this working correctly. Opened a PR to fix this issue.

[macdjord]

FYI: This issue also exists in version 2.14.2.

Edit: Never mind; my mistake.

I had two models, one which defined all the fields of my data-model (some read-only, some write-only, some neither) but left them optional, and another that had the same fields but all mandatory, the idea being that the first model would be the input to the edit endpoint (so the user sends only those fields they want to change) and the second is the input to the create endpoint (where all fields are mandatory) and the output to both (since all fields are always present in the responses.

Problem was, I defined the second model by using allOf to compose the first model together with a second schema that just added the required list. But of course, the rule about readOnly and writeOnly overriding the required list only applies when the readOnly or writeOnly tag is in the same schema as the required list.

Once I changed the second schema to duplicate the readOnly and writeOnly tags from the first schema, it worked as expected.

[chrisinmtown]

Please note this is a V3 bug. Summarizing a discussion from the PR so it's part of the issue: basically Connexion must not reject a request based solely on the presence or absence of a field marked as required and readOnly. It's ok for the field to be missing, that's the original problem raised here, and FWIW that matches my understanding of "readOnly". Counterintuitively - strictly according to JSON schema validation - it's also ok for the field to be present.

For anyone else trying to reproduce this, here's a bash script to submit requests:

#!/bin/bash
if [ $# -ne 1 ]; then
    echo "Usage: $0 file.json"
    exit 1
fi
set -x
curl -v -X PUT localhost:5000/objects/5ABB78EA-39DB-440F-8922-E15C1B28B722 --json @"$1"