Descripción
src/parser/openapi3/authorizationDefinition.js (líneas 14-19) recorre components.securitySchemes y hace break en cuanto encuentra el primer scheme con type: oauth2:
for (const i in oAuthDefinition) {
if (oAuthDefinition[i]?.type === 'oauth2') {
definition = oAuthDefinition[i]
definitionKey = i
break
}
}
Solo se genera UN request "Get OAuth2 Token - <definitionKey>" y un único pm.environment.set("<definitionKey>", ...).
Sin embargo, src/parser/authorization.js asigna a cada endpoint el nombre real de su propio securityScheme (tomado de su security: en el spec), y src/generator/authorization.js arma el header Authorization: {{<ese nombre>}} por endpoint.
Si el spec define más de un securityScheme oauth2 (caso común: uno para clientCredentials y otro para password), los endpoints que usan el scheme que NO fue detectado primero quedan referenciando una variable de entorno que nunca se rellena.
Reproducción
Usando example/petstore.yaml (define OauthClientCredentials y OauthPassword, ambos type: oauth2, usados en distintos endpoints):
node index.js -f petstore.yaml -c <config con host/port básicos>
Resultado:
- Solo se genera el item
000.001.Get OAuth2 Token - OauthClientCredentials, que hace pm.environment.set("OauthClientCredentials", ...).
- Los endpoints que requieren
OauthPassword (ej. POST /pets, PUT /pets/{petId}) usan el header {{OauthPassword}}.
- En el
.postman_environment.json generado, OauthPassword existe como variable pero con "value": "" — nunca se popula porque no existe ningún request que le haga pm.environment.set.
Impacto
Todas las requests que dependen de un securityScheme oauth2 distinto al primero detectado se ejecutan sin token válido → fallan con 401 en el runner, sin ningún aviso en la generación.
Fix propuesto
Quitar el break y generar un request "Get OAuth2 Token - <key>" por cada scheme type: oauth2 presente en securitySchemes, cada uno haciendo pm.environment.set sobre su propio nombre de variable (igual que ya se hace correctamente para uno solo).
Descripción
src/parser/openapi3/authorizationDefinition.js(líneas 14-19) recorrecomponents.securitySchemesy hacebreaken cuanto encuentra el primer scheme contype: oauth2:Solo se genera UN request "Get OAuth2 Token -
<definitionKey>" y un únicopm.environment.set("<definitionKey>", ...).Sin embargo,
src/parser/authorization.jsasigna a cada endpoint el nombre real de su propio securityScheme (tomado de susecurity:en el spec), ysrc/generator/authorization.jsarma el headerAuthorization: {{<ese nombre>}}por endpoint.Si el spec define más de un securityScheme
oauth2(caso común: uno paraclientCredentialsy otro parapassword), los endpoints que usan el scheme que NO fue detectado primero quedan referenciando una variable de entorno que nunca se rellena.Reproducción
Usando
example/petstore.yaml(defineOauthClientCredentialsyOauthPassword, ambostype: oauth2, usados en distintos endpoints):Resultado:
000.001.Get OAuth2 Token - OauthClientCredentials, que hacepm.environment.set("OauthClientCredentials", ...).OauthPassword(ej.POST /pets,PUT /pets/{petId}) usan el header{{OauthPassword}}..postman_environment.jsongenerado,OauthPasswordexiste como variable pero con"value": ""— nunca se popula porque no existe ningún request que le hagapm.environment.set.Impacto
Todas las requests que dependen de un securityScheme oauth2 distinto al primero detectado se ejecutan sin token válido → fallan con 401 en el runner, sin ningún aviso en la generación.
Fix propuesto
Quitar el
breaky generar un request "Get OAuth2 Token -<key>" por cada schemetype: oauth2presente ensecuritySchemes, cada uno haciendopm.environment.setsobre su propio nombre de variable (igual que ya se hace correctamente para uno solo).