Unable to use environment variables when configuring params for AuthenticationOAuth2

[mnapoleon]

Code Versions
Spring Boot - 3.2.2
Spring Pulsar - 1.0.2

When starting up an application that using application.yaml to provide the authentication params there are no issues and PulsarTemplate is created.
Example of pulsar client section of application.yaml

  pulsar:
    client:
      authentication:
        plugin-class-name: org.apache.pulsar.client.impl.auth.oauth2.AuthenticationOAuth2
        param:
          issuerUrl: https://auth.streamnative.cloud/
          audience: urn:sn:pulsar:o-vox1v:dev
          privateKey: data:application/json;base64,ewo<cutoff to avoid secrets>
      service-url: <our url>

When switching to using environment variables like this the application does not start.

SPRING_PULSAR_CLIENT_AUTHENTICATION_PARAM_AUDIENCE=urn:sn:pulsar:o-vox1v:dev SPRING_PULSAR_CLIENT_AUTHENTICATION_PARAM_ISSUERURL=https://auth.streamnative.cloud/ SPRING_PULSAR_CLIENT_AUTHENTICATION_PARAM_PRIVATEKEY= data:application/json;base64,ewo<cutoff to avoid secrets

After some debugging I found that the code configuring the PulsarClient is excepting properties named issuerUrl and privateKey (camelCase). But when the values are supplied via environment variables the properties in the property map are named issuerurl and privatekey (no camelCase).

The application does not start and the exception is
org.apache.pulsar.client.api.PulsarClientException$UnsupportedAuthenticationException: org.apache.pulsar.client.api.PulsarClientException$UnsupportedAuthenticationException: java.lang.IllegalArgumentException: Required configuration parameter: issuerUrl

I am wondering if this a bug or expected behavior.

[onobc]

Hi @mnapoleon ,

Thanks for the report. Yes, prior to moving the auto-configuration into the Spring Boot project (in the 0.2.x Spring Pulsar version) we had a chunk of code that handled these cases. However, the Boot team wanted to make it simpler and consistent w/ what they do for the Spring Kafka project. Details are https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#messaging.pulsar.connecting.auth (in the "NOTE" section). I believe this will work if you use exact case on the property name portion of the env var (e.g. SPRING_PULSAR_CLIENT_AUTHENTICATION_PARAM_issuerUrl). Let us know if:

1. this works for you
2. is acceptable for you.

Thanks

[mnapoleon]

@onobc - Thanks for the information. Unforunately when using the environment variable names with the exact casing as you describe the camel casing is still lost in the properties map.
It would be acceptable if it was behaving as expected.
The only variable it really matters to me for in privateKey as it contains the encoded client credentials.

I was able to find a work around I think.
Setting my env vars like above
SPRING_PULSAR_CLIENT_AUTHENTICATION_PARAM_AUDIENCE=urn:sn:pulsar:o-vox1v:dev SPRING_PULSAR_CLIENT_AUTHENTICATION_PARAM_ISSUERURL=https://auth.streamnative.cloud/ SPRING_PULSAR_CLIENT_AUTHENTICATION_PARAM_PRIVATEKEY= data:application/json;base64,ewo<cutoff to avoid secrets

And then referencing the env vars in my application.yaml file like this

  plugin-class-name: org.apache.pulsar.client.impl.auth.oauth2.AuthenticationOAuth2
  param:
    issuerUrl: ${SPRING_PULSAR_CLIENT_AUTHENTICATION_PARAM_ISSUERURL}
    audience: urn:sn:pulsar:o-vox1v:dev
    privateKey: ${SPRING_PULSAR_CLIENT_AUTHENTICATION_PARAM_PRIVATEKEY}

Seems to work.

[onobc]

It would be acceptable if it was behaving as expected.

Ha. Fair enough @mnapoleon. This was assuming that the exact casing would work. I also landed on the same workaround as you (mapping the env var in the yml) but you beat me to the issue. Thanks.

I will get this added to the SB docs as a workaround for now.

[onobc]

Resolved via 6b6f0be