409 Conflict Error on Login via /login Endpoint in Self-Hosted Docker Setup

[Kodalinq]

Hi team 👋

I'm encountering a 409 Conflict error when trying to log in via the /login endpoint. Here's what I’ve observed:
The request is a standard POST to /login.
The server responds with 409 Conflict and the message:
"The request could not be processed due to a conflict."
The response appears even before any form validation is triggered.
Request is sent via browser from https://tracker.my-domain.com/login.

Headers and environment details:

I’m using the application via Docker proxying it through Nginx proxy manager, and also using Cloudflare proxy as a second proxy.
I have also tried disabling proxying and logging directly into the software with no results
I haven't made any changes to the authentication logic manually.

Remote address (as seen in DevTools): [IP_addr]:10809
strict-origin-when-cross-origin seems to be enforced.
Possible involvement of CSRF or session mismatch.

What I've tried:

• Cleared browser cache/cookies
• Disabled browser extensions (proxy/VPN related)
• Tried in incognito mode and another browser

Could you help me understand what may be causing the 409?
Happy to provide any configs or routes if needed.

Thanks in advance 🙏

[Kodalinq]

I’ve just completed a fresh installation of the system — everything went smoothly, and the application was working as expected.

However, after I tested the password reset functionality, the login process broke again, and I started receiving a 409 Conflict error consistently.

This is the exact same issue I encountered previously, and I was hoping a clean reinstall would solve it — but it seems to be directly triggered by the password reset flow.

Steps to reproduce:

• Install SolidTime from scratch.
• Confirm everything works — login functions correctly.
• Use the “Forgot Password” / reset password feature.
• After resetting, attempt to log in.
• Receive 409 Conflict error.

Possible cause: This might be related to session or CSRF token conflicts after the reset process. The cookies (solidtime_session and XSRF-TOKEN) may not be syncing correctly after the password change.

Let me know if any logs or request headers would help — happy to provide more details.

[korridor]

Please check if the values in the debug healthcheck endpoint are correct. https://docs.solidtime.io/self-hosting/testing#health-checkdebug

[Kodalinq]

{
"ip_address": "x.x.x.x",
"url": "https://tracker.my-domain.com/health-check/debug",
"path": "health-check/debug",
"hostname": "tracker.my-domain.com",
"timestamp": 1746521425,
"date_time_utc": "2025-05-06 08:50:25",
"date_time_app": "2025-05-06 08:50:25",
"timezone": "Etc/UTC",
"secure": true,
"is_trusted_proxy": true
}

[korridor]

Thanks, that looks good so far. Is the IP address the correct external IP of your computer?

[korridor]

Can you lock into the logs and tell me if there are any exceptions?

[Kodalinq]

Hi,

Yes, the ip_address field in the health‐check output (x.x.x.x) is indeed the public IP of the machine from which I’m accessing the tracker.

I’ve just searched the application logs around the time of my latest login attempts and didn’t find any stack traces or “Exception” entries—only the routine cURL timeout warnings for update/telemetry pings. Here’s a snippet from storage/logs/laravel-2025-05-16.log:

[2025-05-16 01:00:13] production.WARNING: Failed to check for update {…}
[2025-05-16 13:00:12] production.WARNING: Failed to check for update {…}
[2025-05-16 13:00:18] production.WARNING: Failed send telemetry data {…}
No errors or exceptions around the /login endpoint appeared in the logs.

Could you point me to where SolidTime would log a failed CSRF or login conflict exception? If there’s a specific log channel or file I’m overlooking, I’ll check that next. Thanks!