App "brute forces" server if signed out

[stratacast]

Steps to reproduce

1. Open app
2. Session gets invalidated somehow (time/app update?)
3. Open app and try to sign back in

Expected behaviour

If you are signed out, the sign in should go as expected

Actual behaviour

App gets a "Too many requests. There were too many requests from your network. Retry later or contact your administrator if this is an error" message.

When this user tried to sign back in, the server would see the sign in as a brute force attempt. The app was in a middle state of functioning but not authenticated to the server. So, as the user was in the app trying to sign back in, the app would make HTTP requests, trying to access (likely cached) content in the background from the remote server but failing because of an invalid session.

Logs

{
  "reqId": "",
  "level": 0,
  "time": "2022-08-23T17:11:34-07:00",
  "remoteAddr": "",
  "user": "user",
  "app": "workflowengine",
  "method": "PUT",
  "url": "/remote.php/dav/files/user/path/to/content",
  "message": "No flow configurations is going to run Block access to a file",
  "userAgent": "Mozilla/5.0 (iOS) Nextcloud-iOS/4.4.2",
  "version": "24.0.4.1",
  "data": {
    "level": "0",
    "app": "workflowengine"
  }
}

And many more like this as the client was constantly trying to PUT and PROPFIND resources.

Reasoning or why should it be changed/implemented?

If the app isn't authenticated and the user needs to sign in again, the app should cease to make any unnecessary HTTP requests to the server, so it doesn't classify failed HTTP requests as brute force attempts.

Environment data

iOS version: e.g. iOS 15.5

Nextcloud iOS app version: 4.4.2

Server operating system: FreeBSD 13.1-RELEASE

Web server: nginx

Database: PostgreSQL 13.7

PHP version: 8.0.20

Nextcloud version: 24.0.4.1

[stoamandl]

I had the same problem after updating to 4.4.2. Fail2ban and also the NC internal app Bruteforce blocked my IP. The problem was that after the update the login was required. However, after each new login comes almost simultaneously again a logout and it seems that the app has not saved the data. No matter whether you do it with the normal password or by means of app token. After I restarted the Iphone (11) with 15.6.1 this behavior was gone and the login was saved.

[askuri]

@stoamandl 's suggestion of rebooting has worked on one of my user's iPhones.

User 1

Got logged out and single login attempt "brute forces" the server, locking him out.

"too many request from your network" -> restart helped

User 2

User had the same problem initially. I asked her to update all her apps (Nextcloud not included), which has resulted in this error on login: (Translation: Error - The process could not be finished.) A restart didn't help in this case.

For those locked out, you can delete the brute force limit from the database: DELETE FROM nextcloud.oc_bruteforce_attempts where metadata like "%username%"; replace username by the actual username.

[ne20002]

I can confirm this. Actually I wasn't able to reconnect my friends device due to being blocked by brute force app. She's now coming to my place so I can reconnect her as my local network is excluded from brute force.

[FelipeNishino]

I've also encountered this problem a few days ago. From reading logs the issue seems similar to @stratacast 's description Since my use case is just a personal cloud I just whitelisted my ip on fail2ban for now and reauthenticated my device, will pay attention on following days if problem somehow shows up again.

[MonsieurLanza]

Same issue here. I had to continuously DELETE FROM … during the login process.

Then once logged for the first time, it spawned an error asking for credentials and disconnected the user. I had to re-login.

This second time, there were no lines to delete in the bruteforce table.

My guess is the disconnection happens server side, and the app fails to understand what is happening, sends loads of requests to the server until you manage to log in somehow… 🤷🏽‍♀️ During this phase reaching the login page is very hard and slow , my guess is the login view is not what the app expects.

Then, once logged in (with continuous DELETEs, remember) it somewhat finally finds out that the user has been disconnected (analyses past 401 responses ?) and disconnects client side.

You can then quietly re login for real.