DataCore

English

日本語

English

日本語

Appearance

User Accounts ​

A DataCore Community account is what ties a plugin listing or bundle to an identifiable owner instead of a free-text "author" field, and lets you delete your own listings later.

Register / log in ​

Register with an email, username, and password (min. 8 characters) at the community site, or from the login prompt that appears the first time you try to post from the main Web UI. A session cookie is issued immediately — you can browse and even complete registration while unverified, but posting requires a verified email.

Email verification ​

Registering sends a verification email with a link like http://localhost:5273/verify-email?token=.... If the registry has no SMTP_HOST configured (the default for local/demo use), that email is instead written to a file in registry/data/outbox/ — read it with:

bash
docker compose exec registry sh -c "cat data/outbox/*<your-email>*"

and open the link inside. Configure SMTP_HOST/SMTP_PORT/SMTP_USER/SMTP_PASS/MAIL_FROM on the registry service for real delivery.

Password reset ​

"Forgot password?" on the login form sends a reset link the same way (real email or data/outbox/). The endpoint always returns success regardless of whether the email is registered, so it can't be used to check whether someone has an account.

GitHub sign-in ​

"Continue with GitHub" requires the operator to register their own OAuth App at https://github.com/settings/developers and set three environment variables on the registry service:

  • GITHUB_CLIENT_ID
  • GITHUB_CLIENT_SECRET
  • GITHUB_CALLBACK_URL (must exactly match the callback URL registered with GitHub, e.g. http://localhost:4001/api/v1/auth/github/callback)

Without these, the sign-in button returns a clear 501 GITHUB_OAUTH_NOT_CONFIGURED error rather than failing silently. A GitHub-authenticated account is treated as email-verified immediately, since the email came from GitHub itself.

Sessions ​

Sessions are a signed JWT in an httpOnly cookie, valid 30 days. Without a fixed JWT_SECRET set on the registry service, a random secret is generated on every container start — meaning every existing session is invalidated whenever the container restarts. Set JWT_SECRET to a fixed value for anything persistent.