android
android copied to clipboard
Custom headers for all requests
Hello, it would be nice to have possibility to add custom headers via app to all requests. As I have for example nextcloud behind CloudFlare, I can proxy access via CloudFlare authentication what provides additional security that only authorized users will end up on Nextcloud instance. They have possibilty to generatr service accout token which is after that used in headers as auth mechanizm.
Regards Stepan
I think this is out of scope for this app, as it is not a feature that will be used by most of the users.
@rullzer what do you say from security perspective?
I think this would be an incredibly useful feature, especially with nextcloud securing sensitive data a zero day would be really bad so having an extra layer would be sweet.
Wouldn't then client certificates be the better and more widely adopted way to add a security layer?
@tobiasKaminsky yes client certificates could be used however the nextcloud app doesn't currently support them. Custom headers with a token are much nicer for enterprise as you can generate tokens for each user rather that having many certificates. Plus tokens are generally easier to work with.
+1 this, would love to be able to add a custom web header in requests from the app.
+1 too, can see many might not use it, but having the extra layer for those of us with smaller setups and less capability for certificate management (or manipulation on ios/android) will certainly appreciate it! Raised this as a feature request for OwnCloud, they're not keen at all for their app etc.. here's hoping!
Resorting to configuring reverse proxy to interrogate user agent data sent by the app is a possible cheat, but doing that when wanting to assign keys to different people quickly gets out of hand...
+1, many run NextCloud behind a reverse proxy with SSO providing proxy forward auth. This is critical for security as it makes it so that any attacker can only access the reverse proxy and the SSO provider without being authenticated, drastically reducing the attack surface.
Is there a another app that works like that, so that I can check, how this works? Or any kind of how to? :)
Immich does this as of 1.107: https://github.com/immich-app/immich/discussions/10758
Works quite nicely.
PR is: https://github.com/immich-app/immich/pull/10588/files
Main obstacle right now would be that there is no way to access settings, before logged it. So it is a chicken <-> egg thingie…
Solution would be to have an extra config on server selection screen.
Something like an "advanced configuration" button on the server login would keep it clean and tidy. If you know you need headers you'd heading in that direction anyways presumably.
When using client certs, we can detect that those are needed.
As I am not an expert with cloudflare, do you know if this sends a specific http return code, if such a custom header is needed? This way we could detect it on first checking the server address and only then show it to the user.
No I don't believe so, if anything cloudflare would likely return a HTTP 403, but that's not strictly indicative of headers being required of course.
For example - personally I just use a locally hosted reverse proxy and if it's missing any auth I just 404 the request (to dissuade further proving attempts against that specific path).
Tossing in my two cents.. I am just running into this now and as I search for a solution to provide for Zero Trust security, I am finding many other people in the same boat. Many give up and settle on using Cloudflare to block known bots, and restrict IPs to one continent, but many like me aren't ready to give up.
Using the Cloudflare app launcher One Time Pin is easy enough when using an actual browser. When configured for challenge, before you can pass through the reverse proxy, you are met with a challenge page where you establish your identity according to which ever rules the admin wishes. Other methods are available as alternatives to ensuring the visitor has an email address at a set of restricted domains, like using a Google login to establish identity.
But for the IOS app and Mac file Sync tool (I imagine exactly the same for Windows and Android), the app cannot understand that it is receiving a challenge page, so just assumes it hit a real old Nextcloud site or some foreign site.
If we can simply provide the app with two header values (but maybe more for other solutions to other problems that people have) to include in requests on a settings page, then on requests with a Service Token ID and a Service Token Secret encoded into the headers (equiv of curl -H "CF-Access-Cient-Id: 2345678..." - H "CF-Access-Client-Secret: 65dbc9022...") then CloudFlare can be provisioned to give the app requests a ByPass from establishing identity.
I'm just testing this with curl right now, and am not really a html, cookies, headers guy, but when I don't provide the valid token in the heads, CF provides a 302 redirection to the Cloudflare access login. But when I provide a valid token in the headers I get the NextCloud login page html.
I do notice that when being proxied through CloudFlare (with the valid token) I am getting a HTTP/2 200 whereas directly to NextCloud from a local machine, I get a HTTP/1.1 200 OK.
Both via Cloudflare and direct on-net provide back 7 the cookies from NextCloud, so CF doesn't seem to be adding any, but does add a couple headers to the response back to the user, CF-RAY and CF-CACHE-STATUS, I imagine it wants them back on subsequent requests.
I am available to do whatever testing the team may need on this.
tobiasKaminsky wrote:
When using client certs, we can detect that those are needed. As I am not an expert with cloudflare, do you know if this sends a specific http return code, if such a custom header is needed? This way we could detect it on first checking the server address and only then show it to the user.
With my throwaway prototype, the extra headers are simply ignored by NextCloud when I am local to it and not accessing through CloudFlare. I have an on-net DNS that returns local 192... addresses for Nextcloud and Collabora when the FQDN is queried. It's a pretty easy augment. Offer the option of extra header value. If the user provides, use them. Always. Now yeah, it would be cool if it's a well used feature to support the user storing them against their Nextcloud profile and including them in a QRCode, but that would be way beyond any initial scope.
The other thing that is nice about this is that the same URL and entry points (on edge proxy and internal proxy, present) can be used, where the service token simply acts as a bypass to the usual authentication if present.
At least with cloudflare, you essentially need to use a second sub domain or path if you want your service to be accessible via mTLS certs OR other auth like an IdP login, which then means more complicated setup at the origin. This is a somewhat common desire, where clients that can handle auth that makes use of challenges like an IdP redirect (that goes in front of the service and isn't integrated with it like the oidc_client app) can use that for convenience where no prior setup is required to access the service, but clients that cannot still have a way in via alternative means that require a minimal additional setup, like adding a service token.
I imagine this is true with other providers as there's a fundamental difference in the approaches. With the token approach the edge proxy (CF here) can check if it's present right away as is and perform routing as appropriate. With mTLS crts, the proxy must request them from the client first, and if the client doesn't understand this (like nextcloud) then there is no trivial way for the server to know that's why the handshake failed and fall back to another auth rule.
So although less common, service token headers are much more flexible and easy to utilize for the hoster.
Bump this. This is critical to ensure services behind the reverse proxy don't need to disable auth to get access. Please is there a place people can vote? Sorry if I was being a spammer of "+1".
Another +1 for this 👍 It'd be amazing to have this so we further secure our nextcloud installations 🙏 (just like @DanielPuckett, also happy to do any testing!)
This would be fantastic together with Pangolin https://github.com/fosrl/pangolin
+1