Sign-in Methods & Account Security
Manager supports password, Google, GitHub, WeChat, and Weibo sign-in. The sign-in page shows only providers that a platform administrator has enabled and fully configured.
First external sign-in
Provider email and display name are form suggestions only. You must confirm a username and email, accept the Terms and Privacy Policy, and verify the message sent by this service. A provider's email_verified assertion never becomes a local email credential.
If the external identity is unbound but you already have a local account, choose "link existing account" and verify its username/email and password. Accounts are never merged merely because two email strings match.
Signing in to an account that still needs verification
When an account has not confirmed its email yet, signing in with the correct password no longer answers "username or password is incorrect". The page shows a pending-verification block instead: the masked address the message went to (for example a***@ex****.com), a "resend verification email" action, and a link to the verification page. A wrong password still gets the unchanged generic rejection, which reveals nothing about whether the account exists or what state it is in.
The resend action on the sign-in page and the one on the verification page are two different entry points:
- Sign-in page (password already proven) reports the real outcome. Asking again too soon returns "too many requests" together with how long is left, and a refused attempt does not consume the day's allowance.
- Verification page (no password) shows the same neutral success message for every address, so it cannot be used to probe which accounts exist.
The authorization the sign-in page hands out lasts up to 24 hours and is renewed on every use. After signing out, completing verification, or letting it lapse, sign in once more to request another resend. It rides on the browser session, so a session idle timeout configured below 24 hours becomes the effective limit.
Pending-verification recovery
Before local email confirmation, the account remains pending. Signing in again with the same external identity returns to recovery, where you can resend the message or correct the email. Closing public registration does not block recovery for an account that was already created.
A verification mail is written in the language of the request that asked for it: your explicit interface-language choice when you made one, otherwise your browser's language, and English when neither is Chinese or English. The language is fixed when the mail is queued, so switching the interface language afterwards does not rewrite a mail that was already sent or is still queued.
When a verification link is invalid or expired, the page shows an email input and a resend action. To prevent account enumeration, this anonymous entry point displays the same neutral success message whether or not that address exists or still needs verification; rely on the delivered email rather than the UI response. If you know the account password, resending from the sign-in page reports the real outcome.
Link, unlink, and set a password
Open Account Settings → Sign-in methods. Link and unlink require a fresh, action-bound check using the current password or an already-linked provider. An external-only account can verify through a linked provider and then set its first password. The last usable sign-in method cannot be removed.
Session impact
Link/unlink updates browser authorization: the current session remains after the successful action, while older browser sessions fail their next protected HTTP request. Confirming an email change invalidates all older browser sessions.
These actions do not actively disconnect an established signaling WebSocket or WebRTC session; remote-connection credentials have a separate lifecycle.
Provider data
Manager stores stable external account identifiers and may retain an email suggestion/display name for UI use. It does not persist provider access or refresh tokens. See the portal Privacy Policy for the full disclosure.