can't login into admin page

[andrei-miron]

Hi,

I just installed Bulwark and configured to work with a Stalwart 0.16.9 server.
I can login into email without any problems but I'm not able to login into admin page. I don't see any error message not in the web page or the log. Even with log_level increased to debug I don't see anything in the logs:
Bulwark Webmail v1.7.4
[DEBUG] 2026-06-23T06:11:31.989Z ConfigManager loaded {"configKeys":11}
[INFO ] 2026-06-23T06:11:31.991Z Admin dashboard enabled (password loaded from admin.json)
Admin dashboard initialized
[INFO ] 2026-06-23T06:11:31.993Z telemetry: scheduler not started {"consent":"off"}
[INFO ] 2026-06-23T06:11:31.996Z version-check: scheduler started {"nextInMs":230727}
[DEBUG] 2026-06-23T06:11:54.443Z Config requested
[DEBUG] 2026-06-23T06:12:07.779Z Config requested
[INFO ] 2026-06-23T06:12:15.817Z Admin dashboard enabled (password loaded from admin.json)

Is there any way to regain control?

Thanks,
Andrei

[andrei-miron]

For anyone else having this problem: connecting to bulwark as a Stalwart administrator I have access to Bulwark administrator panel.

[wspch0p]

I ran into the same symptom with Bulwark 1.7.8: entering the correct /admin password simply reloaded the login page without showing an error.

After investigating, the password was not the problem. The audit log recorded admin.login for the correct password, while deliberately incorrect passwords produced admin.login_failed. The browser, however, never retained an admin_session cookie.

The reason appears to be in lib/admin/session.ts:

secure: process.env.NODE_ENV === 'production',

The Docker image sets NODE_ENV=production, so the admin session cookie is always marked Secure. When Bulwark is accessed over plain HTTP, the browser refuses to retain that cookie. The password check succeeds, Bulwark redirects to /admin, but the next request has no session cookie and is redirected back to the login page. This makes it look as though the password was rejected.

COOKIE_SECURE=false does not fix this because the admin cookie does not use the regular cookie configuration helper. The normal cookie helper honours COOKIE_SECURE, but setAdminSessionCookie() does not. The same code also appears to remain in the current main branch.

Putting Bulwark behind HTTPS immediately fixed the problem for me. After TLS was enabled, the admin_session cookie was retained and the local Bulwark administrator login worked normally.

Logging into webmail with a Stalwart administrator account may expose Stalwart administration-related functionality, but that is separate from Bulwark’s local /admin password and session stored in admin.json.

It would probably be useful for the admin session cookie either to honour COOKIE_SECURE, like the other session cookies, or for the setup/admin login page to clearly report that HTTPS is required.

TLDR: This issue appears when accessing the /admin via HTTP. The COOKIE_SECURE=false is only honored for the webmali login, not /admin endpoint. The isse can be mitigated by putting a reverse proxy serving HTTPS traffic in front of Bulwark.