0
Answered

Mobile app OAuth2: "Strict mode: No HTTP allowed"

StudioWhy LLC 11 months ago updated 8 months ago 6

Ever since we switched to using OAuth2 for authorization, I have been unable to access the server via the Nextcloud mobile app. I am able to see the sign-in screen, but clicking "SSO' displays this error. This is even with "Allow unsafe access over plain HTTP." selected as well. We are using Keycloak as our authentication server.

Answer

Answer
Answered

The problem was that the web server was incorrectly configured to redirect requests to a path without trailing slash (example: https://my-server/filerun), to the same path with trailing slash (http://my-server/filerun/), but the redirect was missing the HTTPS, redirecting to HTTP instead.

Under review

I am afraid that error message is not from FileRun. Perhaps the OAuth2 server you are using, should be accessed via HTTPS instead of HTTP.

All the solutions I've seen talking about this involve changing a configuration with the Nextcloud Application being accessed:
How to resolve “Strict mode, no HTTP connection allowed!” ? | The World's Linux Journal (linuxfun.org)
Android app [Strict mode: No HTTP connection allowed]. x64 OMV5, Docker, Nginx reverse proxy : NextCloud (reddit.com)

I have tried adding them to the $config array like this: $config['overwriteprotocol'] = 'https';
But these configurations did nothing for FileRun. Are there corresponding configurations for FileRun I could set?

Please use the contact form (https://filerun.com/contact) to provide an URL and a test login to check this out for you.
It's probably the HTTP or proxy server configuration injecting a CSP header causing this.

Answer
Answered

The problem was that the web server was incorrectly configured to redirect requests to a path without trailing slash (example: https://my-server/filerun), to the same path with trailing slash (http://my-server/filerun/), but the redirect was missing the HTTPS, redirecting to HTTP instead.

I should note that I am still running into this issue and have sent instructions on how to replicate it with a fresh Docker image to the team.

I ended up fixing the issue by generating and using a self-signed certificate with apache in the docker container and exposing port 443 instead of 80. Then my reverse proxy communicates with it via https.