-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User status requests cause many 404 not found responses #26793
Comments
user_status is the app
it's valid that a user has no status. Yet we should probably not return a 404 in that case. Similar to nextcloud/text#820. But using the http status codes is common for backend frontend communication. Most libraries already handle such cases. Using a own schema (e.g 200 with a "status" field) must be implemented ourself.
sounds good to me. match the user_status endpoint and filter out the 404 responses. as said it's valid to have no status and so the 404 response. |
cc @nextcloud/server-triage Is it feasible to implement returning a different response than 404 here? |
fail2ban on 404 is not suitable on nextcloud atm. Either you start to manually exclude those or you don't ban on 404. From my POV this is a will not fix |
How to use GitHub
Is your feature request related to a problem? Please describe.
I want to monitor server logs with fail2ban, but a feature in Nextcloud 20 is causing a lot of 404 responses:
/ocs/v2.php/apps/user_status/api/v1/statuses/daniel => 404 not found
Describe the solution you'd like
I'm not really sure if this is a bug or feature request, I could not even quickly find exactly which feature or app is causing this. It happens as soon as the dashboard is displayed after a login. Maybe Talk? All I want is for it not to happen :) Logically, all known users should have a status, but it seems not. Would it go away if I deleted a particular app?
Describe alternatives you've considered
A nasty alternative within my power would be to match the request location and return something else. But as I'm removing all 2xx and 3xx response entries from the nginx access log, to give fail2ban less work to do (i.e. to avoid race conditions on disc io) then it would have to be some other 4xx code, and I don't see one which would match the situation.
Additional context
This is seen on a home-use instance, but I also manage one for a client where more users are active. The amount of 404's there will be a lot more...
The text was updated successfully, but these errors were encountered: