Custom Header support for iOS app

[FinleyJDev]

Is your feature request related to a problem? Please describe.
My evcc is secured behind a cloudflared tunnel and then exposed to the internet. I can't access it from the iOS app because it doesn't support the authentication via safari.

Describe the solution you'd like
The easiest way would be to add an option in the app where you can configure custom headers that are sent with every request made. This way you could add Cloudflare service auth tokens.

Describe alternatives you've considered
I've considerd trying to use the cookies one gets from authenticating in the browser from cloudflare but that doesn't work or i don't have the technical know how.

[naltatis]

See also #35

[naltatis]

Just came across the immich app. They're doing exactly this to support cloud flare tunneling.
immich-app/immich#10588

Guess this would be a pretty straightforward option which also has the benefit of working stateless (no intermediate login flow and cookies we have to take care of). Would also work for widget use-cases.

Screenshot from the immich iOS app

[naltatis]

Ok, looks like my enthusiasm was premature. react-native-webview does not support adding custom headers reliably (only on first request).

[FinleyJDev]

I did some quick research and found a solution/workaround for this

https://github.com/react-native-webview/react-native-webview/blob/master/docs/Guide.md#working-with-custom-headers-sessions-and-cookies

Working with custom headers, sessions, and cookies

Setting Custom Headers

In React Native WebView, you can set a custom header like this:

<WebView
  source={{
    uri: 'http://example.com',
    headers: {
      'my-custom-header-key': 'my-custom-header-value',
    },
  }}
/>

This will set the header on the first load, but not on subsequent page navigations.

In order to work around this, you can track the current URL, intercept new page loads, and navigate to them yourself (original credit for this technique to Chirag Shah from Big Binary):

const CustomHeaderWebView = (props) => {
  const { uri, onLoadStart, ...restProps } = props;
  const [currentURI, setURI] = useState(props.source.uri);
  const newSource = { ...props.source, uri: currentURI };

  return (
    <WebView
      {...restProps}
      source={newSource}
      onShouldStartLoadWithRequest={(request) => {
        // If we're loading the current URI, allow it to load
        if (request.url === currentURI) return true;
        // We're loading a new URL -- change state first
        setURI(request.url);
        return false;
      }}
    />
  );
};

<CustomHeaderWebView
  source={{
    uri: 'http://example.com',
    headers: {
      'my-custom-header-key': 'my-custom-header-value',
    },
  }}
/>;

[naltatis]

@FinleyJDev yes, I found that in the docs. But artificial reloads don't seem like sustainable approach. I guess we also have issues with in-page requests (api calls, web socket). @Maschga

[Maschga]

I also found the workaround, but I deliberately don't want to use it.
It solves a problem that is a bug in the web view. The author of the blog, which dates from 2016 (sic!), also writes about this. This behaviour must be integrated internally into the web view; it is not something that can or should be built around the web view component.
In addition, the workaround means that the component has to be re-rendered for every request, and evcc has many dependencies in the user interface.
And it also makes the code of the evcc app more complicated.