Eric Daly
Eric Daly
I would recommend you use the log functions inside of each of the activity lifecycle methods, then monitor logcat while your app moves through each of them. This will give...
I think that makes sense to reset the brute force attempts after successfully logging in, but in my opinion there should also be a way to do this from the...
Thanks @MorrisJobke, that makes sense. I didn't realize there was a maximum timeout of only 30 seconds. Actually according to https://nextcloud.com/blog/security-in-nextcloud-12-bruteforce-protection-and-rate-limiting-for-developers/ it says the timeout can go up to 60...
> This would then make the throttling useless. 😉 Because then the attacker only needs to wait a few seconds and knows if the password was correct and then could...
Thanks @BornToBeRoot, that clears it up for me 👍 So bypassing the delay with successful credentials negates the whole thing because the attacker should have to wait the full amount...
@melikyuksel If you're using version 13 or later it should automatically reset the throttling once you log in successfully. If not, you can check in the database and manually delete...
I ran into this recently. Our use-case is using the EKS cluster for gitlab-runners with cluster-autoscaler. I know, people are recommending Karpenter but we are just not there yet. Adding...
bad bot! The only missing information would be input from the development team!
This issue has been manually marked as not stale by me, right now.
@nextcloud-bot bad bot