[Bug]: allOf in a request body silently drops fields for x-www-form-urlencoded requests
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 76/100
Direzione di ricerca
Start at iter_all_of_schemas in openapi_core/validation/schemas/validators.py and reproduce the form-body example with OpenAPI.from_dict and MockRequest. Verify that the allOf fields are retained and cast as expected, with no silent loss; add a regression test covering the x-www-form-urlencoded request.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Actual Behavior
If a form request body (application/x-www-form-urlencoded) uses allOf, and one of the allOf parts has a field that isn't a string (a boolean, integer,
or object), that whole allOf part gets dropped. Every field in it disappears from the result, even the string ones.
There's no error. result.errors is empty, so it looks like the request succeeded. The fields just silently go missing. A log.warning("invalid allOf schema found") is printed.
In the example below, the result is {'name': 'widget'}. Both enabled (a boolean) and label (a string) are gone, because they're in the same allOf part as the boolean.
Expected Behavior
The result should be {'name': 'widget', 'enabled': True, 'label': 'hello'}.
If I write the same fields as one plain object instead of using allOf, it works correctly and enabled is cast to True:
"schema": {
"type": "object",
"properties": {
"name": {"type": "string"},
"enabled": {"type": "boolean"},
"label": {"type": "string"},
},
}
# -> {'name': 'widget', 'enabled': True, 'label': 'hello'}
allOf should give the same result. And valid data should never be dropped
without an error.
Steps to Reproduce
Run this (only openapi_core is needed):
from openapi_core import OpenAPI
from openapi_core.testing import MockRequest
spec = OpenAPI.from_dict({
"openapi": "3.0.1",
"info": {"title": "repro", "version": "1.0.0"},
"paths": {"/items": {"post": {
"requestBody": {"content": {"application/x-www-form-urlencoded": {"schema": {
"allOf": [
{"$ref": "#/components/schemas/Flags"},
{"type": "object", "properties": {"name": {"type": "string"}}},
]
}}}},
"responses": {"200": {"description": "ok"}},
}}},
"components": {"schemas": {"Flags": {
"type": "object",
"properties": {
"enabled": {"type": "boolean"},
"label": {"type": "string"},
},
}}},
})
request = MockRequest(
host_url="http://example.com", method="post", path="/items",
data=b"name=widget&label=hello&enabled=true",
content_type="application/x-www-form-urlencoded",
)
result = spec.unmarshal_request(request)
print(result.body) # {'name': 'widget'}
print(result.errors) # []
Output:
invalid allOf schema found
{'name': 'widget'}
[]
OpenAPI Core Version
0.23.1
OpenAPI Core Integration
none (openapi_core.testing.MockRequest); first seen with Django
Affected Area(s)
unmarshalling, schema
References
This looks related to the older "allOf is treated as type: any" reports (#147, #149), but here the effect is different: valid data is silently dropped,
instead of just a confusing error message. It only happens for form bodies, where values arrive as strings.
It seems to come from iter_all_of_schemas in openapi_core/validation/schemas/validators.py. Each allOf part is checked against the raw value and skipped if it doesn't match. For form bodies the values are still strings at that point, so a part with enabled: {type: boolean} fails against the string "true", gets skipped, and its fields are never read.
Anything else we need to know?
No response
Would you like to implement a fix?
Yes
- Lingua principale
- Python
- Stelle
- 368
- Fork
- 140
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di python-openapi/openapi-core
-
kind/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
python-openapi/openapi-core#1188 · 2 commenti ·
-
kind/bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
python-openapi/openapi-core#1225 · 2 commenti ·
-
[Bug]: Query parameter validation fails to match empty string when listed as a valid enum value Apertakind/bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
python-openapi/openapi-core#1210 ·
-
kind/bug kind/bug/confirmed
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
python-openapi/openapi-core#1180 · 3 commenti ·
-
kind/enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 32/100
python-openapi/openapi-core#1142 ·
Tutte le issue di python-openapi/openapi-core
Issue simili
-
documentation help wanted
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
simonw/sqlite-utils#872 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100