11.0.2 incredibly slow login

ℹ️ Support
,
11

That’s exactly as I have proxying set up at home because a) it requires no additional config and b) I’m the only user :slight_smile:

That makes me wonder why it would registered a wrong password if that did indeed happen. There are no failed login attempts.

Any other reason it would kick in?

12

@lukasreschke implemented it :see_no_evil:So he can answer this :wink:

1 Like
13

At the moment this is the only place where it is used.

1 Like
14

Also a report here on github:

1 Like
15

Same problem . Taking too much time to login after clicking login button

Rebooted web server (sudo service apache2 restart)
Added ‘auth.bruteforce.protection.enabled’ => false, to the config

But it is not fixed

16

Hello,

I can confirm the same problem in a fresh installation using Samba AD as user store. Problem for both AD users and local (nextcloud) users. Zabbix monitoring show a login time of around 16~18 seconds. Server is also behind a proxy. I have tried the solution: auth.bruteforce.protection.enabled’ => false , but did not work.

Thank you.

17

Anyone else facing this type of problem, please update the issue:

18

Just solved the problem.

While the brute force protection was activated, the MySQL table “oc_bruteforce_attempts” has filled with my username, triggering the bruteforce protection when I tried to login.

After disabling bruteforce protection, I still encountered the problem. Rebooted my NC server: still same problem. I could not reboot my MySQL server, it is a production machine. However, I issued the following mysql statement:

“DELETE FROM oc_bruteforce_attempts”

SHAZAM! Now the login is quick, and the table is not filling up again.

The bruteforce protection needs more intelligence. Like when a user / IP succeeds, clear the info from the table. I disabled it for the moment. When it gets good enough, I will reactivate it. For the moment, just using strong passwords should do the trick. And other protection in frnt of the web server.

Have a good one!

2 Likes
19

Resolved !
Many thanks, i disabled this bruteforce feature.
Is there pull requests to fix this ?

I am using beta version 12 :’(

20

we have same issue with a very similar architecture to original poster. Will try x-forward-for setting as first step (will help track other issues on client servers anyway, been on the todo list for… )

21

hello,
it seems to me, that the X-Forwarded-For is not used as intended.
I have in the oc_bruteforce_attempts table always the proxy ip.

i have tested the forwarded-for setting of the proxy with a little php script where i get my real ip on HTTP_X_FORWARDED_FOR

(I’m on nextlcoud 11.0.3)
Someone else can reproduce the same behavior?

am I missing a setting?

greetings,
seti

22

“DELETE FROM oc_bruteforce_attempts”

Danke! My nextcloud setup had suddenly gotten very slow after making some config changes (namely adding memcache), and I was getting another unrelated error to confuse the issue, defintiey stinks to suddenly have everything slow to a crawl for no apparent reason, but then again, it’s nice to know that protection is there, and now I know a little more about nextcloud internals. (this is 11.0.2)

23

A post was split to a new topic: Expired password and bruteforce detection

24

Thanks!
I had the same problem and solved it with the SQL statement

DELETE FROM xyz_bruteforce_attempts

Thanks a lot.

25

This worked. THANK YOU! Saved me a huge headache.

26

Thanks this speeded up my nextcloud instances allot!

27

Would be best if this issue is reported here actually:

28

Awesome!

I just registered to report that this bug still exists in Nextcloud 13.0.2 and that the remedy is still the same.
In my case logging in lasted over a minute, and the Linux Nextcloud client couldn’t even connect (probably because of a timeout).

29

You are sure it is the same bug. Check the related github issues and open a new one if you still can reproduce this error. I’m closing this (answers to such old topics mostly get no attention).