Unexplained 404 Error after setting up Voidauth

[mpldr]

I got Voidauth setup, but for some reason get a 404 on an API call which makes me unable to login:

2026-04-13T16:09:35.809485890Z {"level":"info","message":"Starting VoidAuth Server","timestamp":1776096575809}
2026-04-13T16:09:35.951184105Z {"level":"debug","message":"Session Domain: '0x6d70.de'","timestamp":1776096575950}
2026-04-13T16:09:36.156451794Z {"level":"info","message":"Connected to postgres database.","timestamp":1776096576155}
2026-04-13T16:09:36.574244474Z {"level":"debug","message":"Attempting SMTP email connection.","timestamp":1776096576572}
2026-04-13T16:09:37.191496160Z {"level":"info","message":"Listening on port: 3000","timestamp":1776096577191}
2026-04-13T16:09:38.206586361Z {"level":"info","message":"SMTP email connection verified.","timestamp":1776096578206}
2026-04-13T16:20:20.139483168Z {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"80.249.116.144","method":"GET","path":"/api/user/me"},"response":{"statusCode":401}},"timestamp":1776097220134}
2026-04-13T16:20:20.204802470Z {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"80.249.116.144","method":"GET","path":"/api/public/config"},"response":{"statusCode":200}},"timestamp":1776097220202}
2026-04-13T16:20:20.234679722Z {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"80.249.116.144","method":"GET","path":"/api/interaction/exists"},"response":{"statusCode":404}},"timestamp":1776097220232}

This is what the login form looks like:

The frontend seems to struggle with the response on /api/interaction/exists being the non-JSON: "Not Found". Is this a known issue that I have just missed? How do I manage to log in?

Edit: This is reproducible. Even after tearing down the environment and recreating it from scratch, this still happens.

[notquitenothing]

The 404 response being un-processable by the frontend framework is expected, if annoying. The regular initialization flow for a 'fresh' login page is to check for an existing interaction session (/exists), and if not found create one (auth endpoint api), and then check again (/exists again). Can you double check and see if these steps are happening in your logs?

[mpldr]

Explicitly setting SESSION_DOMAIN to auth.… leads to .auth.0x6d70.de being in the cookie

[notquitenothing]

It looks like setting APP_URL='https://auth.0x6d70.de' should indeed produce a session domain of 0x6d70.de. So I am not sure why the login page at https://auth.0x6d70.de/login should be able to have an interaction-session cookie set at that domain. In my own testing it looks like the leading . is added automatically, at least by my browser.

I have been working on refactoring some of the Session Domain logic, which might be where the issue lies. If you want, you could try the latest unreleased changes on the :edge tag. If you want to try that, I would recommend backing up your database if you have an existing setup, then to unset SESSION_DOMAIN, set ENABLE_DEBUG='true', and verify the APP_URL variables. I would be interested to see if you can log in, and if not there are any interesting lines in the debug logs.

[mpldr]

I get sent to the auth endpoint and run into the same issue again immediately

[notquitenothing]

That is how I would expect it to look if the interaction session cookie could not or was not set. Your site is only passing to the client the x-voidauth-interaction cookie, but other cookies are required and should be coming back with various requests as well. If you are using a WAF or some other type of control where you can whitelist cookie names, this is the list that is required:

• x-voidauth-interaction
• x-voidauth-interaction.sig
• x-voidauth-resume
• x-voidauth-resume.sig
• x-voidauth-session
• x-voidauth-session.sig

Let me know if this helps

[mpldr]

I could confirm that four Set-Cookie headers are sent and the reverse proxy only forwards one.

[notquitenothing]

Were you able to fix the reverse proxy settings to pass the required headers forwards?

[mpldr]

Yes, it seems my caching layer was, despite not caching, modifying the response. I have since changed the caching layer. Now it is working as expected.