Is there a way to do edge auth for the apps?

[markrosan8]

Is there any way to implement edge authentication across all clients? Browsers can store cookies, but it seems that the iOS and other apps most likely don’t have support to store custom cookies and headers.

Is it possible to add custom cookie/custom header support?

[markrosan8]

@Svanvith @micbar @guruz @kulmann

I submitted two PRs to add custom http header functionality to the ios app. Would appreciate a review and thoughts.

opencloud-eu/ios#42
opencloud-eu/ios-sdk#6

[guruz]

I wonder if opencloud-eu/ios#42 and opencloud-eu/android#116 by @paolostivanin are two sides of the same coin...
(Having (pre?)authorization closer to network level)

[paolostivanin]

Related yes, but they're at different layers:

• iOS Add custom HTTP header support for proxies ios#42 adds custom HTTP headers (application layer / L7), useful for things like Cloudflare Access JWTs, proxy-injected auth headers, basic auth on the proxy, etc.
• Android Security: Add mTLS client certificate support android#116 adds mTLS client certificates (transport layer, during the TLS handshake), useful when the edge requires a client cert, e.g. Cloudflare mTLS or a corporate CA gating access. Both solve the broader "authenticate to the edge/reverse proxy before reaching OpenCloud" problem, but they're not interchangeable, some setups need one, some the other, some both. My own setup is CF mTLS -> NPM -> homelab, where only the cert works; a Cloudflare Access deployment would need the header path instead.

Long term it probably makes sense to have both options available on both platforms.

[guruz]

@paolostivanin @markrosan8 What's your opinion on this UI?

Advantages to me are:

• Does not change main settings UI with "expert" settings that most people would not need.
• Makes it clear it's per account (per URL) and not per app. So you don't accidently leak anything with multi account.

Downsides:

• Set once, never change it approach could backfire if cert needs to be updated (expiry) or header changes.
• (Not sure about custom cookie that you mentioned in your initial post.. they would come from server and need to be stored? I think the OpenCloud approach is to have everything with access_token/refresh_token from OIDC but yes that's not edge..)

@kulmann @dragotin etc.. what could be a better approach to have those kind of connectivity settings?

[paolostivanin]

Agree on the per-account scoping, it's better.

The "set once, never change" concern is the bigger issue with the mockup though. mTLS certs typically rotate (annually?) and edge headers/JWTs change, so there has to be an edit path after setup, otherwise the only escape on cert expiry is remove + re-add the account, which loses local state. I'd suggest: configure during setup and expose the same fields under an account properties / edit screen later, not only at setup time.

On custom cookies: I think those are a niche-of-a-niche. Cloudflare Access, oauth2-proxy etc. set their own cookies after their flow runs, and as long as the HTTP client persists the cookie jar it just works.

Custom headers have a much stronger case (static API keys, basic auth on the proxy, CF Access service tokens). Custom user-supplied cookies I'd skip until someone shows up with a concrete use case.

[guruz]

expose the same fields under an account properties / edit screen later, not only at setup time.

For the record:
iOS existing menu with long press (I did not add anything there, not sure what is the best way):

Edit goes to:

Manage Goes to:

Android does not seem to have per account setup yet, I added the gear icon here in mockup which could expose the same menu as in wizard(?):

[RihanArfan]

The proposed UI looks great but I think we should have one tab for setting headers, which opens a popup with a list. A user may need to add more than one header (in the case of Cloudflare Access two, one for Cloudflare Access ID and another for the secret).

[guruz]

@RihanArfan Hmm, right now opencloud-eu/ios#42 supports only one header but maybe if support multiple headers (or other things like custom cookies at some point) maybe my UI proposal is not so good after all (with the menu) but it should be a sub view instead where all things could be set.

E.g. the gear icon goes to a sub view that has:

• (m)TLS client certificate
• custom HTTP header list
• (...future other things that need to be set before connecting and can't get be negotiated via webfinger/OIDC)

[micbar]

@guruz i do not want to scope-creep this, but are these settings also possible to roll out via a mobile device management (MDM)?
I am thinking of a way to tell the mdm where to put a mtls certificate.

[markrosan8]

@guruz @micbar any final decisions made on this feature which I should modify in my PR?

• regarding the location of these settings, they must be accessible after the sign in flow too. Requiring users to delete their account and start setup fresh to change authentication tokens or certificates is not the best UX.

• regarding the per account headers...I agree that per account is canonically right, but in my original code review I remember there was some meaningful complexity there (I don't recall the exact point, though). This would be an extremely niche use case, and I don't see its value. But if it's a hard constraint, I will look into it again. There may be an easier way to scope it to each account.

[markrosan8]

Also, is there a target date for the next release?

[markrosan8]

@guruz @micbar just a note, immich has these exact options, and it works perfectly. So, maybe worth a look here to use a similar UI?

[cursed-sparrow]

I see custom header was merged: opencloud-eu/ios#59

It would have been better as suggested above to be able to configure multiple headers, like in many other apps.

In my case I use Pangolin to access Opencloud. With Pangolin shareable links, we can generate these 2 headers: P-Access-Token-Id and P-Access-Token