Webviews using authentication aren't working anymore

[Mr-iX]

Description
The latest version of the OpenHAB iOS app broke the ability to use Webviews behind authentication.

In my sitemap I have the following lines:

Text item=co2_sensor_co2 valuecolor=[<800="green",<1000="orange",<1400="red",>1399="maroon"] {
    Webview icon=none url="https://<ip>/static/grafana-co2-buero.html" height=6
}

This webview points to the following file (/etc/openhab/html/grafana-co2-buero.html):

<iframe src="https://<ip>/grafana/d-solo/obZEuT3Mk/openhab?orgId=1&refresh=30s&from=now-24h&to=now&panelId=7"></iframe>

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />

<style>
iframe {
    width: 100%;
    height: 100%;
    border: none;
    display: block;
}

body {
    margin: 0;
    padding: 0;
    overflow: hidden;
}
</style>

To access the html as well as the Grafana instance an HTTP basic auth is required. The same username and password are required as for accessing OpenHAB itself, therefore those are set in the "Home Settings" tab of the OpenHAB iOS app.

However in the latest version of the OpenHAB iOS app these credentials are not sent anymore for Webviews and therefore I'm getting a 401 Authorization Required error. In a previous version of the OpenHAB iOS app this already worked fine for many years.

Screenshots

Expected behavior
Webview is shown using the same credentials for authentication similar to the Basic UI that already comes with openHAB:

App:

• Version 3.1.41 (98)

Smartphone:

• Device: iPhone 17

openHAB:

• Version 5.1.0 (Release Build)

[aMU5Ed]

Same here. WebUI in mobile browser works well, but latest iOS Client has broken this funtionality

[timbms]

We could apply a setting-based approach, ie extend alwaysSendBasicAuth to webviews.

There's already a per-connection toggle "Always send credentials" (alwaysSendBasicAuth) used by AuthorisationMiddleware for API requests. We could check the same flag in onReceiveSessionTaskChallenge to skip the host check:

if challenge.protectionSpace.host == URL(string: configuration.url)?.host
    || challenge.protectionSpace.host == "home.myopenhab.org"
    || configuration.alwaysSendBasicAuth {

• Pro: Minimal code change, reuses existing UI/setting
• Con: Sends openHAB credentials to any host a webview navigates to (e.g. a third-party CDN loaded by an iframe). This is a real credential leak risk.

@digitaldan What do you think?

[digitaldan]

What were we doing before where it was working? I have not been following the sitemap logic changes close enough to know off the top of my head.

[timbms]

The history has three phases:

Phase 1 — Header injection (pre-2020): WebUITableViewCell injected Basic Auth credentials directly into every webview request as an Authorization header. This worked but sent credentials to every URL the webview loaded, regardless of host.

Phase 2 — Challenge/response (Aug–Oct 2020):

• 1140537 (Aug 2020) — Added WKNavigationDelegate.didReceive challenge to WebUITableViewCell, which delegates to onReceiveSessionChallenge. This lets the server ask for credentials via a 401 challenge, and the app responds with stored credentials when the host matches the configured openHAB URL.
• 0286b79c (Oct 2020, iOS App always sends basic authorization header to WebView URLs even when no credentials are set #586/Remove basic auth from webview #587) — Removed the header injection, relying solely on the challenge/response pattern. This was intentional — it's more secure because credentials are only sent when the server asks and the host matches.

Phase 3 — SwiftUI regression (recent): When the SwiftUI sitemap renderer was introduced, WebRowView was created as the SwiftUI equivalent of WebUITableViewCell but the respondTo challenge delegate method was never ported to its Coordinator. So webviews in the SwiftUI renderer silently fail on 401 challenges.

Fix: b88f390c adds the missing respondTo challenge delegate to WebRowView.Coordinator, matching the existing behavior in WebUITableViewCell.

[digitaldan]

Fix: b88f390 adds the missing respondTo challenge delegate to WebRowView.Coordinator, matching the existing behavior in WebUITableViewCell.

Not sure i'm following the Ai summary, what fix is this? In any case, can we reimplement the last working solution:?

Edit: Also can we reuse the credential auth and client cert logic we already use elsewhere in our http client for this? That would be nice.

[timbms]

Fix: b88f390 is a fix for a regression in branch openapigen-swiftui

[timbms]

Also can we reuse the credential auth and client cert logic we already use elsewhere in our http client for this?

Precisely what is already done.

[timbms]

Yes the answer was AI generated. This is so convenient.

But I still no clear cut why it was working. I think it was taking the risk to leak the credentials

[digitaldan]

But I still no clear cut why it was working

Sorry i'm still confused 😄 , its working now with the fix or no its still not working with the previous logic added back in?

[timbms]

@Mr-iX

In a previous version of the OpenHAB iOS app this already worked fine for many years.

@aMU5Ed

Same here.

What was the version working for you?

[aMU5Ed]

@Mr-iX

In a previous version of the OpenHAB iOS app this already worked fine for many years.

@aMU5Ed

Same here.

What was the version working for you?

For me the versions before 3.1.2 (release on the app store) were working

[timbms]

What was the version working for you?

For me the versions before 3.1.2 (release on the app store) were working

That is strange because release version 3.1.2 is based in development version 3.1.42 (99). While the version @Mr-iX reports the problem on is 3.1.41 (98).

[Mr-iX]

@Mr-iX

In a previous version of the OpenHAB iOS app this already worked fine for many years.

@aMU5Ed

Same here.

What was the version working for you?

Unfortunately I don’t know anymore. Is there any way to downgrade and test old versions? Happy to try any „development build“.