You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Depending on the defined authentication scheme, then the generated ApiClient class does not compile. Indeed, it may incorrectly create a new HttpBearerAuth object, but correctly detect that this class does not need to be imported.
It was detected when trying to generate an OpenApi client using kerberos negotiation with type http and scheme negotiate together together with with bearer auth and generator java with library resttemplate. Additionally to the "missing" HttpBearerAuth import, the wrong values were set into the created authentication object. With some other java generators, the class was imported but there was still an incorrectly created HttpBearerAuth object. Because the root cause of both issues is the same, I group them together here.
openapi-generator version
Initially observed with version 4.2.3, but examples below reproduced with version 6.4.0, generator java with library resttemplate, but I think that it also affects following libraries: java/apache-httpclient, java/feign, java/okhttp-gson, java/resteasy, java/retrofit, java/retrofit2, java/vertx, java/webclient, kotlin-client/jvm-ktor, kotlin-client/multiplatform
Related issues/PRs
Could not find anything related existing.
Opened #15220
Suggest a fix/enhancement
When searching for the root cause of the observed behavior, I noticed the following parts of ApiClient mustache templates:
However, the implementation behind hasHttpBearerMethods is as follows:
/** * Returns true if the specified OAS model has at least one operation with HTTP bearer. * * @param authMethods List of auth methods. * @return True if at least one operation has HTTP bearer security scheme defined */publicstaticbooleanhasHttpBearerMethods(List<CodegenSecurity> authMethods) {
if (authMethods != null && !authMethods.isEmpty()) {
for (CodegenSecuritycs : authMethods) {
if (Boolean.TRUE.equals(cs.isBasicBearer)) {
returntrue;
}
}
}
returnfalse;
}
As a result, I think that it would be more appropriate for the ApiClient mustache templates to contain:
or for hasHttpBearerMethods to be defined as follows:
/** * Returns true if the specified OAS model has at least one operation with HTTP bearer. * * @param authMethods List of auth methods. * @return True if at least one operation has HTTP bearer security scheme defined */publicstaticbooleanhasHttpBearerMethods(List<CodegenSecurity> authMethods) {
if (authMethods != null && !authMethods.isEmpty()) {
for (CodegenSecuritycs : authMethods) {
if (Boolean.TRUE.equals(cs.isBasic) && Boolean.FALSE.equals(cs.isBasicBasic)) {
returntrue;
}
}
}
returnfalse;
}
The PR linked to this issue proposes the first option as correct fix, since it avoids creating HttpBearerAuth objects for unknown types of authentications.
Command line used for generation
The below examples were built with openapi-generator-maven-plugin and following maven plugin configuration:
importcom.example.commons.myapi.openapi.client.auth.Authentication;
@javax.annotation.Generated(value = "org.openapitools.codegen.languages.JavaClientCodegen", date = "2023-03-03T15:42:11.398+01:00[Europe/Berlin]")
@Component("com.example.commons.myapi.openapi.client.ApiClient")
publicclassApiClientextendsJavaTimeFormatter {
...
privateMap<String, Authentication> authentications;
...
protectedvoidinit() {
...
authentications = newHashMap<String, Authentication>();
authentications.put("signatureAuth", newHttpBearerAuth("signature"));
// Prevent the authentications from being modified.authentications = Collections.unmodifiableMap(authentications);
}
}
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /C:/dev/myapi-example/myapi-openapi/myapi-openapi-client/target/generated-sources/com/example/commons/myapi/openapi/client/ApiClient.java:[112,50] cannot find symbol
symbol: class HttpBearerAuth
location: class com.example.commons.myapi.openapi.client.ApiClient
Expected result
I'm not really sure of what should be expected in this case.
maybe the same with the missing import added:
importcom.example.commons.myapi.openapi.client.auth.Authentication;
importcom.example.commons.myapi.openapi.client.auth.HttpBearerAuth;
@javax.annotation.Generated(value = "org.openapitools.codegen.languages.JavaClientCodegen", date = "2023-03-03T15:42:11.398+01:00[Europe/Berlin]")
@Component("com.example.commons.myapi.openapi.client.ApiClient")
publicclassApiClientextendsJavaTimeFormatter {
...
privateMap<String, Authentication> authentications;
...
protectedvoidinit() {
...
authentications = newHashMap<String, Authentication>();
authentications.put("signatureAuth", newHttpBearerAuth("signature"));
// Prevent the authentications from being modified.authentications = Collections.unmodifiableMap(authentications);
}
}
or rather without the authentication listed at all. Is it still a missing feature for the resttemplate library? (I see that a class called HttpSignatureAuth exists for generators jersey2 and jersey3)? If so, I would expect the following code to be generated:
importcom.example.commons.myapi.openapi.client.auth.Authentication;
@javax.annotation.Generated(value = "org.openapitools.codegen.languages.JavaClientCodegen", date = "2023-03-03T15:42:11.398+01:00[Europe/Berlin]")
@Component("com.example.commons.myapi.openapi.client.ApiClient")
publicclassApiClientextendsJavaTimeFormatter {
...
privateMap<String, Authentication> authentications;
...
protectedvoidinit() {
...
authentications = newHashMap<String, Authentication>();
// Prevent the authentications from being modified.authentications = Collections.unmodifiableMap(authentications);
}
}
The text was updated successfully, but these errors were encountered:
tiffmaelite
changed the title
[JAVA/Kotlin] Bug invalid code for ApiClient generated when using an http authentication which is neither basic nor bearer
[JAVA/Kotlin] Bug invalid code for ApiClient generated when ONLY using an http authentication which is neither basic nor bearer
Mar 3, 2023
…ttpBearerAuth (or HttpBasicAuth) for other http auth methods (such as http signature auth or custom schemes) (#15220)
* remove http signature from test yaml when not supported
* do not use HttpBearerAuth for signature auth or other unsupported http auth method
ignore unsupported http auth method unless generated code would not compile (in which case, an exception is thrown)
* [Java] fix use of isBasic condition
* [kotlin] fix use of isBasic condition
Description
Depending on the defined authentication scheme, then the generated ApiClient class does not compile. Indeed, it may incorrectly create a new HttpBearerAuth object, but correctly detect that this class does not need to be imported.
It was detected when trying to generate an OpenApi client using kerberos negotiation with type http and scheme negotiate together together with with bearer auth and generator java with library resttemplate. Additionally to the "missing" HttpBearerAuth import, the wrong values were set into the created authentication object. With some other java generators, the class was imported but there was still an incorrectly created HttpBearerAuth object. Because the root cause of both issues is the same, I group them together here.
openapi-generator version
Initially observed with version 4.2.3, but examples below reproduced with version 6.4.0, generator java with library resttemplate, but I think that it also affects following libraries: java/apache-httpclient, java/feign, java/okhttp-gson, java/resteasy, java/retrofit, java/retrofit2, java/vertx, java/webclient, kotlin-client/jvm-ktor, kotlin-client/multiplatform
Related issues/PRs
Could not find anything related existing.
Opened #15220
Suggest a fix/enhancement
When searching for the root cause of the observed behavior, I noticed the following parts of ApiClient mustache templates:
However, the implementation behind
hasHttpBearerMethods
is as follows:As a result, I think that it would be more appropriate for the ApiClient mustache templates to contain:
or for hasHttpBearerMethods to be defined as follows:
The PR linked to this issue proposes the first option as correct fix, since it avoids creating HttpBearerAuth objects for unknown types of authentications.
Command line used for generation
The below examples were built with openapi-generator-maven-plugin and following maven plugin configuration:
Steps to reproduce
Scenario 1: using both bearerAuth and kerberosNegotiation
Side-note: According to https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#securitySchemeObject any scheme listed on https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml is supported, which includes scheme "negotiate", which is widely used by corporate APIs. But this is not yet supported by openapi-generator with java libraries, so I would expect it to be simply ignored in this case.
OpenAPI declaration file content
Observed result
Expected result
Scenario 2: using only bearerAuth
OpenAPI declaration file content
Observed result
Expected result same as observed
Scenario 3: using only kerberosNegotiation
OpenAPI declaration file content
Observed
Expected
Scenario 4: using only signatureAuth
Side-note: I could not find it listed on https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml but the open api generator documentation and tests contain mention of this http authentication type
OpenAPI declaration file content
Observed result
Expected result
I'm not really sure of what should be expected in this case.
maybe the same with the missing import added:
or rather without the authentication listed at all. Is it still a missing feature for the resttemplate library? (I see that a class called HttpSignatureAuth exists for generators jersey2 and jersey3)? If so, I would expect the following code to be generated:
The text was updated successfully, but these errors were encountered: