Admin server surfaces DEFAULT_SUPERUSER_EMAIL via 'list envs' but init_default_admin() hardcodes the account

[kobihikri]

Summary

The admin server surfaces DEFAULT_SUPERUSER_EMAIL as if it configures the bootstrap admin account
(it shows up in list envs and in services.py), but init_default_admin() hardcodes the email and
password, so setting DEFAULT_SUPERUSER_EMAIL (or DEFAULT_SUPERUSER_PASSWORD) doesn't change the
account that actually gets created.

To be clear up front: I know the admin@ragflow.io / admin default is documented and that the
CLI can change the password after first login — so this isn't a "hidden default credentials" report.
It's a smaller consistency point: one of these env vars looks effective but isn't wired to the
bootstrap.

Observation

admin/server/services.py lists DEFAULT_SUPERUSER_EMAIL among the environments the admin service
reports (services.py:440):

env_kv = {"env": "DEFAULT_SUPERUSER_EMAIL", "value": os.getenv("DEFAULT_SUPERUSER_EMAIL", "admin@ragflow.io")}

But the account is actually created by init_default_admin()
(admin/server/auth.py:88-100), which hardcodes both fields:

default_admin = {
    "password": encode_to_base64("admin"),
    "email": "admin@ragflow.io",
    ...
}

check_admin() (same file) hardcodes the same pair. Neither reads DEFAULT_SUPERUSER_EMAIL /
DEFAULT_SUPERUSER_PASSWORD. (A separate, opt-in path, api/db/init_data.py:init_superuser, does
read DEFAULT_SUPERUSER_PASSWORD, but the admin server doesn't use it.)

Effect (inference)

An operator who sets DEFAULT_SUPERUSER_EMAIL=me@corp.com before first boot will see that value
echoed by list envs, but the admin account that gets created is still admin@ragflow.io — the env
var reads as effective while the behaviour is fixed. DEFAULT_SUPERUSER_PASSWORD is similarly not
honoured by this path.

Possible directions (your call)

• Have init_default_admin() / check_admin() read os.getenv("DEFAULT_SUPERUSER_EMAIL", "admin@ragflow.io")
  and os.getenv("DEFAULT_SUPERUSER_PASSWORD", "admin"), matching what list envs implies, or
• Drop DEFAULT_SUPERUSER_EMAIL from the surfaced env list so it doesn't read as effective when the
  bootstrap is fixed.

Happy to open a small PR either way. Thanks for RAGFlow — the admin CLI is a nice touch.

_{AI-assisted; I reproduced the code paths and the list envs doc example myself against commit e54e7ec7ef6c.}

[dosubot]

Hi @kobihikri! I'm Dosu and I'm helping the InfiniFlow team.

I can confirm the inconsistency you've identified. In admin/server/services.py, DEFAULT_SUPERUSER_EMAIL is surfaced as a configurable environment variable, but init_default_admin() in admin/server/auth.py hardcodes both the email ("admin@ragflow.io") and password ("admin") without reading those env vars. The check_admin() fallback initialization path in the same file similarly hardcodes the credentials [1].

Interestingly, the API layer's init_superuser in api/db/init_data.py does respect both DEFAULT_SUPERUSER_EMAIL and DEFAULT_SUPERUSER_PASSWORD from the environment — so the pattern for reading these vars already exists in the codebase, it just wasn't applied to the admin server's bootstrap path.

I didn't find any existing issues or PRs tracking this inconsistency, so this appears to be the first report. A PR wiring init_default_admin() and the check_admin() fallback to read from the env vars (matching the pattern in api/db/init_data.py) would make the admin server's behaviour consistent with what list envs implies.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.