I have a new installation of OH3 (openhabian).
I have the HTTP binding installed with 3 identical Things defined (three identical Proliphix IMT550c Ethernet Thermostats). I have created Channels, Links and Items, and can successfully get thermostat properties using the devices’ REST API. However every time that I reboot Openhab, the logs show an auth problem for each of the three things. e.g.:
… [DEBUG] [p.internal.http.HttpResponseListener]… failed: Authorization error
The configured auth parameters are correct, and if I simply view the config in the GUI and re-save (without changes), the things’ auth starts working again. e.g. the following is logged:
… [DEBUG] [nding.http.internal.HttpThingHandler] - Digest Authentication configured for thing ‘http:url:49422d1796’
… [INFO ] [nding.http.internal.HttpThingHandler] - Using the insecure client for thing ‘http:url:49422d1796’.
Curiously, very early in the boot process, the auth seems to succeed. OH logs the same two messages above ( “Digest Auth Configured” and “Using the insecure client”) for each of the three things/endpoints. However, shortly thereafter in the logs I get (for all 3 endpoints):
… [DEBUG] [p.internal.http.HttpResponseListener] - Requesting ‘http://thermostat1.6w.kfife.com/get?OID4.1.13’ (method=‘GET’, content=‘null’) failed: Authorization error
and
[WARN ] [ttp.internal.http.RefreshingUrlCache] - Could not find authentication result for ‘http://thermostat1.6w.kfife.com/get?OID4.1.13’, failing here
Given the characteristics of this failure, and the newness of OH3, I suspect this could be a regression, rather than a problem with my config. I’m happy to post examples/code/how-to-reproduce in the right place with some guidance from the community.
hi! same problem under Windows10 using zulu (java for windows openjdk 11.0.9.1).
boot in debug shows:
Using the insecure client for thing ‘http:url:9670a3c5b5’
Is anyone NOT seeing this behavior in OH3? If so, would be helpful to know so the behavior can be narrowed down to a particular condition (e.g. network/transport/auth idiosyncrasies).
For what it’s worth, after the openhab 3.0.1 update, I am still seeing this HTTP binding Authorization error problem.
It occurs 100% of the time after reboot.
The error stops 100% if I view the ‘thing’ in gui, and then hit ‘save’.
Does anyone have an idea of where I might look for a solution?
Just to mention. I have 7 things for the HTTP binding and do not have any issue. Also restart/boot is absolutely no problem. But there‘s one slight difference. My things are all using the secure client.
Probably because I have either a token or an auth header configured in all my things.
2021-01-27 19:19:27.145 [INFO ] [nding.http.internal.HttpThingHandler] - Using the secure client for thing ‘http:url:dingzWZ’.
Thank you @rpwong for the suggestion. I will do that. I wireshark’ed the conversation and correlated it to the OH trace debug log. It appears that after every reboot (or OH service restart), the http binding ‘thing’ does not attempt to authenticate (Digest) when it sends its http GET. When the endpoint replies with 401 “authorization required”, the OH binding does not re-try with an authenticated request. Instead it gives up and waits for the refresh interval (60 sec), and tries again, also unauthenticated.
By contrast, after one ‘re-saves’ of the http binding thing, the behavior is different. In the post-save scenario, when OH receives the 401 from the endpoint, OH immediately retries (i.e. ~25ms) with an appropriate authenticated GET, and the endpoint replies appropriately (200 OK).
Subsequent GET requests from OH (made on its 60-second interval) are properly pre-authenticated without needing to respond to a failed GET ending in 401 (until the next restart). I will mention @J-N-K here for good measure.
@HaKuNa thank for the datapoint. Yes, it appears you’re using a different kind of auth and of course, TLS.
2021-01-28 21:14:18.442 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to ‘America/Chicago’.
2021-01-28 21:14:18.502 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to ‘41.68568475971216,-86.99541091918945’.
2021-01-28 21:14:18.507 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to ‘en_US’.
2021-01-28 21:14:18.511 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Measurement system set to ‘US’.
2021-01-28 21:14:39.797 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2021-01-28 21:14:46.845 [INFO ] [org.openhab.ui.internal.UIService ] - Started UI on port 8080
2021-01-28 21:14:48.950 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2021-01-28 21:14:50.241 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel
2021-01-28 21:14:50.698 [DEBUG] [nding.http.internal.HttpThingHandler] - Digest Authentication configured for thing ‘http:url:49422d1796’
2021-01-28 21:14:50.702 [INFO ] [nding.http.internal.HttpThingHandler] - Using the insecure client for thing ‘http:url:49422d1796’.
2021-01-28 21:14:50.742 [TRACE] [ttp.internal.http.RefreshingUrlCache] - Started refresh task for URL ‘http://thermostat1.6w.kfife.com/get?OID4.1.13’ with interval 60s
2021-01-28 21:14:50.749 [TRACE] [.HttpDynamicStateDescriptionProvider] - adding state description for channel http:url:49422d1796:GetZoneTemp
2021-01-28 21:14:57.904 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2021-01-28 21:15:01.034 [TRACE] [.HttpDynamicStateDescriptionProvider] - returning new stateDescription for http:url:49422d1796:GetZoneTemp
2021-01-28 21:15:03.388 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2021-01-28 21:15:03.391 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
This server could not verify that you are authorized to access the requested URL. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't know how to supply the credentials required.
Cherokee web server, Port 80
}
2021-01-28 21:15:51.080 [DEBUG] [p.internal.http.HttpResponseListener] - Requesting ‘http://thermostat1.6w.kfife.com/get?OID4.1.13’ (method=‘GET’, content=‘null’) failed: Authorization error
2021-01-28 21:15:51.082 [WARN ] [ttp.internal.http.RefreshingUrlCache] - Could not find authentication result for ‘http://thermostat1.6w.kfife.com/get?OID4.1.13’, failing here
2021-01-28 21:16:00.117 [TRACE] [.HttpDynamicStateDescriptionProvider] - returning new stateDescription for http:url:49422d1796:GetZoneTemp
Opened, re-SAVED thing in GUI (with no changes):
2021-01-28 21:16:35.911 [TRACE] [ttp.internal.http.RefreshingUrlCache] - Stopped refresh task for URL ‘http://thermostat1.6w.kfife.com/get?OID4.1.13’
2021-01-28 21:16:35.913 [TRACE] [.HttpDynamicStateDescriptionProvider] - removing state description for thing http:url:49422d1796
2021-01-28 21:16:35.920 [DEBUG] [nding.http.internal.HttpThingHandler] - Digest Authentication configured for thing ‘http:url:49422d1796’
2021-01-28 21:16:35.922 [INFO ] [nding.http.internal.HttpThingHandler] - Using the insecure client for thing ‘http:url:49422d1796’.
2021-01-28 21:16:35.927 [TRACE] [ttp.internal.http.RefreshingUrlCache] - Started refresh task for URL ‘http://thermostat1.6w.kfife.com/get?OID4.1.13’ with interval 60s
2021-01-28 21:16:35.928 [TRACE] [.HttpDynamicStateDescriptionProvider] - adding state description for channel http:url:49422d1796:GetZoneTemp
Successful GET after SAVE:
2021-01-28 21:17:00.180 [TRACE] [.HttpDynamicStateDescriptionProvider] - returning new stateDescription for http:url:49422d1796:GetZoneTemp
2021-01-28 21:17:35.927 [TRACE] [ttp.internal.http.RefreshingUrlCache] - Requesting refresh (retry=false) from ‘http://thermostat1.6w.kfife.com/get?OID4.1.13’ with timeout 3000ms
2021-01-28 21:17:35.929 [TRACE] [ttp.internal.http.RefreshingUrlCache] - Sending to ‘http://thermostat1.6w.kfife.com/get?OID4.1.13’: Method = {GET}, Headers = {Accept-Encoding: gzip, User-Agent: Jetty/9.4.20.v20190813}, Content = {null}
2021-01-28 21:17:36.070 [TRACE] [p.internal.http.HttpResponseListener] - Received from ‘http://thermostat1.6w.kfife.com/get?OID4.1.13’: Code = {200}, Headers = {Transfer-Encoding: chunked, Date: Fri, 29 Jan 2021 03:17:35 GMT, Server: Cherokee, Content-Encoding: gzip, Vary: Accept-Encoding, Content-Type: text/plain}, Content = {
OID4.1.13=683}
Please let me know if you want the PCAP from this same conversation between OH and Thermostat1
Still works for me. The question is why no authentication result is found even though it has been configured before (according to the log). I have no idea how to debug that.
Would it be helpful if I share the pcap of that conversation? Alternatively if you want to share yours I could compare the the two.
This install was migrated from v 2.5. I’ve seen some examples of configuration cruft (configs pointing to non-existent 2.x directories etc. that I’ve had to clean up manually). I wonder if there’s some kind of persistence problem related to migration, and magically ‘fixed’ when the thing is re-saved, essentially to a ramdisk that lacks persistence due to impropper mapping/zram? Just a thought.
I can Nat you to this device to rule in/out this install.
When I save the HTTP thing, where is the file written to the filesystem?
I’d really like to figure this out. Can you share a PCAP file of your conversation, or conversely I can share mine for the period of service restart, fail, save, succeed. It’s only a few dozen packets.
Would you like to hit my HTTP endpoint? I can whitelist NAT your IP in to the device.
I am no longer involved in the development of openHAB. Maybe someone will investigate and fix if you enter an issue on GitHub. You should reference this thread here.