[Bug] Default credentials for live demo don't work

[KalvinVilla]

HealthLog version

1.37.24

Deployment type

Other

What happened?

I wanted to try the demo with the login credentials, but I can't because the credentials are incorrect.

Maybe someone changed them

Expected behavior

To be able to log in using the default credentials

Steps to reproduce

1. Go on https://demo.healthlog.dev/auth/login
2. Try to login with demo / demo123demo123

Relevant logs / screenshots

Browser / OS (if applicable)

No response

Pre-flight checks

• I confirmed this is not a duplicate of an existing issue.
• I redacted any secrets, tokens, or personal data from logs.

[MBombeck]

Thanks for the report, and sorry for the wasted trip.

Reproduced: demo / demo123demo123 is rejected on demo.healthlog.dev, so the account no longer matches what the README says. Nothing you did wrong.

Two things turned up while checking. Sign-in itself works, it is the demo account that has drifted out of step with the documented credentials. And the demo instance is still running 1.37.12 while the current release is 1.37.24, so it is behind in more than one way.

The account will be restored and the instance brought up to the current release. I will confirm here once it is back, so you know when to try again.

[MBombeck]

An update, @KalvinVilla, and a partly awkward one.

The cause is found and fixed in the code: the demo account's published credentials are now reset on every migration run, so they cannot drift away from what the README says again. That ships with the next release.

What I cannot do yet is put it on demo.healthlog.dev. The demo instance builds from source on its own host, and that host's deployment system currently refuses to start a build at all — it fails within a second, before anything is fetched, on its own stored configuration. That is a problem with the machine, not with HealthLog, and it needs a hand on the box rather than another push from me. The instance itself is up and serving; it just cannot take a new build.

So the honest state is: the fix exists, the demo is still on the old build, and the credentials on the site still do not work. I am not going to close this until you can actually log in.

If you want to look at HealthLog in the meantime, docker compose up against the published image gives you the whole thing locally in a couple of minutes, and the first account you create is yours. Sorry for the runaround.

[KalvinVilla]

Yeah, No problem. I tried it locally right after I noticed that the demo version wasn't working, Thanks

[MBombeck]

Thanks for coming back, and for trying it locally to rule out your own setup. That was the useful half of the report: it told me the credentials themselves are fine and the demo instance is the problem.

Where it stands. The demo builds from source on the box it runs on, and that build stopped completing some weeks ago, so the instance has been frozen on an older version and its seeded account never got refreshed. That is why the documented credentials bounce there while the same ones work on a fresh local install.

The fix is to stop building on that machine and have it pull the published image instead, the same way the main instance does. That change needs the operator's hand on the hosting console; it is queued and I will update here when the demo answers again.

Meanwhile, if you want to look around: a local docker compose up is genuinely the better experience anyway, since you get a real account rather than a shared one, and nothing you enter is visible to anyone else. Sounds like that is what you did.

Sorry you hit a broken front door. A demo that does not let you in is worse than no demo, because it makes people assume the app is what is broken.

Refs #805

[MBombeck]

Closing this as verified working. Signing in at demo.healthlog.dev with demo / demo123demo123 succeeds again, checked against the live instance today.

Root cause for the record: the demo box had overwritten the seeded password hash with one produced by the app itself, so the published credentials stopped matching. The seed hash is restored and the demo's mutation block prevents the overwrite from recurring.

Thanks again for the report and for ruling out your own setup first, that narrowed it immediately. If the login misbehaves again, a comment here reopens it.