Im using Fail2ban to protect web interface from brute forcing password attempts successfully. Failed access via API aren’t logged and wondered if it was possible to configure or add this ability?
adding this makes sense, yes
i’ll do it when i have some time (or someone else might and post a PR)
I’m pretty sure this was added for the API shortly after it was added to the frontend login. But I think the message might be slightly different so fail2ban might need some tweaking.
I’m using PHP logging and picking the failed attempt in nginx error.log. Nothing in error.log and access.log only shows backend.php being accessed.
Any additional info would be great.
Edit: I’m on mobile and just noticed your link, will check it out, thanks!
i just tried it and it works fine, both internal and stderr logging
apologies for user-error guys, Ill go and check config etc. Thank you
Clearly I’m missing some here and wanted to come back and see if you have any pointers to help me debug this further.
I debugged my previous system and could not get an API failed log in attempt error to appear in the logs at all so I created a completely new system based on stretch with Tiny Tiny RSS v17.4 (a6990df), php7.0 & postgres 9.6.
Logs are working fine for failed HTTP accesses - see log_image
API access works / doesn’t work from both Reeder on iOS and OSX depending on the correct password or username entered but no matter what, I just can’t pickup an error for a failed login attempt. I see the nginx access entry correctly but no failed response in error.log or the dashboard panel.
Would appreciate any guidance as to where to look deeper, tt-rss config, the fever code, my nginx config… Id even be happily directed to any more RTFM materials.
I’d call it a day and move on but given the report yours works fine it indicates some config error or lack of user knowledge on my part and Id be curious to resolve. Its not the end of the day, my API passwords are strong.
thanks again
asks for API logs
uses a third party plugin instead of an official API client
well done op
doh! I understand now… I didn’t recognise the official API vs 3rd party API implications, thanks for highlighting it.