Allow logging of failed login attempts

[bertille-ddp]

What are you building with SQLPage ?
I’ve currently built a shared calendar with SQLPage, but I really like the project and will use it some more in the future for other simple apps

What is your problem ? A description of the problem, not the solution you are proposing.
When using the auth module, all login attempts show up the same in the reverse proxy logs (302 HTTP code) whether they’re successful or not. Because of this, it’s not possible to monitor if there is suspicious activity on the login page, with a bad actor trying to bruteforce passwords for example

What are you currently doing ? Since your solution is not implemented in SQLPage currently, what are you doing instead ?
Instead, I’m monitoring if an IP address is hitting the page that handles an auth multiple times in an hour. Any login attempt hits this page once, but when a legitimate user sucessfully logs in, they won’t fave to hit it again because they stay logged in thanks to their session cookie. Multiple hits point towards failed login attempts

Describe the solution you'd like
I’d like for an option in the auth module to return a different HTTP code for a failed login attempt (typically 401) and a successful one (the current 302). This way, failed logins can be logged by the reverse proxy

Describe alternatives you've considered
I’ve tried manually setting the status code to 401 with the ad hoc module, but it didn’t work

[lovasoa]

Hello, and welcome to SQLPage, @bertille-ddp ! Can you share a minimal reproduction of your issue ? Are you using the authentication component ? If so, then setting a custom http response code for failed login attempts should be possible. You could have something like:

select 'status_code' as component, 401 as status where $failed='1';

select 'authentication' as component,
    '$argon2i$v=19$m=8,t=1,p=1$YWFhYWFhYWE$oKBq5E8XFTHO2w' AS password_hash,
    :password as password,
    '?failed=1' as link
where :password is not null;

select 'redirect' as component, '?success=1' as link where :password is not null; -- replace this by creating a session and redirecting the user

select 'login' as component,
    case
      when $failed then 'Bad password. The correct password is "password"'
      when $success then 'You are logged in'
    end as error_message;

As a side note: passwords are protected by argon2 by default, and enforcing some basic password complexity rules should be enough to protect against password bruteforcing. If you are storing sensitive data and want to delegate security to a specialized third party, you can use OIDC: https://sql-page.com/sso/ . Most providers will allow you to setup login rate limits. If you want to implement a basic version yourself, you could have something like

select 'redirect' as component, '?failed=1' as link
from users where username=:username and last_login_attempt>unixepoch('now')-10; -- enforce 10 seconds between two login attempts

[bertille-ddp]

Thanks @lovasoa 🙌

If you still think it’s relevant I could share a minimal reproduction of my issue, but the issue is the same with the example you provided. Indeed, 401 is set as the status of the GET of the redirection, and not as the status of the POST of the login attempt:

[2026-02-10T13:43:59.662Z INFO actix_web::middleware::logger] 127.0.0.1 "POST / HTTP/1.1" 302 87 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:147.0) Gecko/20100101 Firefox/147.0" 0.000723 [2026-02-10T13:43:59.697Z INFO actix_web::middleware::logger] 127.0.0.1 "GET /?failed=1 HTTP/1.1" 401 4052 "http://localhost:8080/" "Mozilla/5.0 (X11; Linux x86_64; rv:147.0) Gecko/20100101 Firefox/147.0" 0.000765

Compare it to another app’s logs:
{ "level":"info", "ts":1770730939.425747, "logger":"http.log.access.log0", "request":{ "remote_ip":"XXX","proto":"HTTP/1.1","method":"POST","host":"XXX","uri":"/api/v0/session","headers":{…} }, "bytes_read":46, "size":0, "status":401, "resp_headers":{…} }
the 401 is on the first request. This means that it will be logged even if the login attempt was scripted to not follow redirections.

I know that it would be better to enforce secure passwords, but I also know from my experience in IT support that it’s safer to consider that passwords will always be insecure, even with the smartest of policies ^^ Belt and suspenders, as one would say

[lovasoa]

Indeed, the status code generated by the authentication component itself is not customizable. But even if it were, you couldn't set it to 401, because http redirections require a 3xx response 🙁