Rest sensor getting header authentication key from sensor

[thejol]

Hi all, looking for a little help.

I’m passing a rest sensor header authentication key via the following sensor as the key changes every hour and is to large for the value field.

headers:
      accept: application/json
      authorization: "{{ states.sensor.bearer_token.attributes.bearer_attribute }}"

When I call this sensor It appears that a carriage return is being placed between Bearer and the key and causes authentication to fail. It looks something like this:

bearer_attribute: >-
Bearer
eyJpZHRva2VuIj12341239askdjf;laksdjl;kj234ljk;lkjzxdfl;kgj;lkasdjlk;j2345;kj…

It needs to be like this:

bearer_attribute: >-
Bearer eyJpZHRva2VuIj12341239askdjf;laksdjl;kj234lj…

Is there a way to prevent the carriage return form being inserted?
When I pass the following as text it works as expected.

authorization: Bearer eyJpZHRva2VuIj12341239askdjf;laksdjl;kj234lj.........

bearer attribute shown below.

      bearer_token:
        value_template: 'OK'
        attribute_templates:
          bearer_attribute: "Bearer {{ states.sensor.token.attributes.access_token }}"

Appreciate any help!

[koying (Chris B)]

Did you check in the template developer that {{ states.sensor.token.attributes.access_token }} doesn’t start with a CR, for whatever reason?

[Edwin_D]

I may be wrong, but I get the feeling you are looking in the wrong place for why it fails. I suspect the token is placed on the next line where you looked at it because it was wordwrapped. I cannot tell (and probably you neither) because you are showing yaml notations, but the header isn’t yaml so we’re not looking at the real thing.

So the first question should be, what is actually ending up in the rest call. The first thing that seems off is the indenting in the first code block, but that might be a pasting error because you didn’t post the whole thing. The second thing is you do not use the state_attr function, but what you did should work as far as I can tell as long as there’s no error. So these are probably not it. I’m not sure if the authentication key supports templating in the first place though. I think it should though.

Seeing what the developer tools display for the template as koying suggested is the first step. Putting that hard coded in the rest api to see if it works is the next step. If that works the template isn’t expanded (or isn’t expanded right), if it doesn’t then something else is wrong. So forst get it working with hard coded bearer token, then proceed.

[Edwin_D]

This posts reports similar issues, suggesting templating is possible… but: unexpected for yaml, they use an Authorization header attribute with a Capital A. Could that be it? It is what the header needs it to be:

Rest sensor - Dynamic Bearer Token (Using Sensor)

So actually found a workaround by not using secrets. The issue is the token bearer is being refresh every time the home assistant starts, and when running the query to get the prices, the “!secret api_key_bearer_static” is equals to “unknown” My solution is: Create helpers as input text where you will store your API key (static) and you bearer key (dynamic) and in my case some static authentication header Store your bearer token from the API in a sensor Create an automation that every time t…

It is also what the docs said (where we both should have looked first )

RESTful Sensor

[thejol]

I thought I had it solved but I’m still getting this error

2024-09-08 10:27:56.748 INFO (MainThread) [homeassistant.components.sensor] Setting up rest.sensor

2024-09-08 10:27:56.748 DEBUG (MainThread) [homeassistant.components.rest.data] Data fetched from resource: {“timestamp”:“2024-09-08T15:27:56.264+00:00”,“status”:401,“error”:“Unauthorized”,“message”:“The token is invalid: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $”,“path”:"

[thejol]

Appears I wasn’t allowing enough time to get a new token before calling the other sensors.

Thanks again all!