EpoCanvas 帳號與會話安全說明
COMMUNITY-010 帳號治理 服務端優先
本頁解釋帳號身份與會話如何被使用。它不會把公開名稱、LV/TL、徽章或瀏覽器裡的一段資料視為安全權限；實際權限以服務端驗證為準。
[!WARNING] 會話令牌等同於短期登入憑證。不要把它貼到評論、Issue、截圖、分析工具或第三方網站。若懷疑令牌外洩，請立即登出並依檢舉與申訴說明聯絡站方。
1. 身份、提供者與角色
帳號資料中的「提供者」與「角色」是不同欄位：
| 概念 | 目前用途 | 不能推導出的結論 |
|---|---|---|
| 訪客 | 沒有持久登入身份，仍可在規則允許下發表部分評論 | 不代表可以 Reaction、查看管理資料或永久保留編輯權 |
| 讀者 | 經有效會話驗證的普通使用者 | 不代表擁有管理員權限或任何審核豁免 |
| 管理員 | 由服務端依受信任身份與管理設定核驗的站務角色 | 不代表可以在公開頁面揭露讀者私密資料 |
| Epomail 提供者 | 由受信任的 Epomail 流程提供身份資訊 | 不代表任何同名或非受信任來源都能取得管理角色 |
| 本地提供者 | 開發或相容流程中的本地讀者身份 | 不會因名稱或前端欄位而自動升級為管理員 |
目前帳號 API 暴露 Epomail 與 local 兩種登入模式；服務端會對角色做安全降級，未經受信任的管理核驗不得取得 admin 角色。LV、TL、角色與徽章的差異，另見身份等級與徽章說明。
2. 登入與會話生命週期
成功登入或建立本地身份後，服務端會發出會話令牌，並在可用時將使用者與會話保存到 D1；開發或沒有資料庫綁定的路徑可能使用程序記憶體保存，這不是生產耐久性保證。
目前身份服務的程式碼設定會話有效期為 14 天。每次需要身份的 API 都應重新檢查令牌與有效期；過期、撤銷或無法核驗的令牌不得繼續用於帳號資料、評論所有權、Reaction 或管理操作。若未來修改期限，應同步更新本頁與測試。
瀏覽器端會為帳號中心與評論元件保存必要的身份資訊，以便在頁面間同步顯示；這些資料不是額外的權限來源。真正的使用者資料與角色仍由服務端會話回查。
3. 登出、過期與失去所有權
- 使用帳號中心登出時，客戶端會清除本地身份資料，並請求服務端撤銷會話；
- 會話自然過期或服務端找不到令牌時，帳號 API 應回傳未授權，前端不得繼續假設已登入；
- 訪客評論的臨時 session token 只用於證明該瀏覽環境曾取得的留言所有權，重新整理、切換瀏覽器、清除資料或失去令牌後可能無法編輯/刪除；
- 無法證明所有權時，站方不會以暱稱、頭像或電子郵件的相似性代替有效鑑權；
- 懷疑帳號被冒用時，不要用新帳號反覆嘗試繞過限制，應先登出、保存必要時間點，再私下通報。
4. 權限如何被判定
服務端權限與身份的最低原則如下：
GET /api/auth/user與GET /api/auth/user-level需要有效會話令牌；- 一般讀者只能查詢自己的身份與等級資料，指定其他電子郵件查詢屬於管理範圍；
- 評論編輯與刪除需要留言所有權的有效 session token，或通過管理員驗證；
- Reaction/Like 需要登入讀者或管理員身份，訪客不能以作者欄位偽造登入；
- 管理員操作仍需使用服務端管理驗證，不會因前端顯示
admin徽章而自動成立。
具體字數、限流、公開欄位與處置規則，請以評論與審核規範及當下服務端回應為準。
5. 個人資料與帳號更新
帳號可以包含名稱、頭像、網站、簡介、時區與地區等欄位。更新前請確認資料不冒充他人、不包含不必要的敏感資訊，也不要把密碼、令牌或支付資料寫入簡介與網站欄位。
若需要查詢、更正或刪除帳號資料，請參考隱私與資料使用說明並以原有帳號或其他合理方式證明請求者身份。刪除帳號或登出不一定能立即移除已進入評論、備份、審計、財務核對或第三方通知的所有資料。
6. 問題回報
遇到無法登入、錯誤角色、會話反覆失效或疑似未授權操作時，請提供發生時間、頁面/API、瀏覽器、錯誤訊息與不含敏感資料的重現步驟。不要提供完整令牌或密碼；安全疑慮請改用安全問題通報規範。
最後更新：2026-10-20。
EpoCanvas 账号与会话安全说明
COMMUNITY-010 账号治理 服务端优先
本页解释账号身份与会话如何被使用。它不会把公开名称、LV/TL、徽章或浏览器里的一段资料视为安全权限；实际权限以服务端验证为准。
[!WARNING] 会话令牌等同于短期登录凭证。不要把它贴到评论、Issue、截图、分析工具或第三方网站。若怀疑令牌外泄，请立即登出并依检举与申诉说明联系站方。
1. 身份、提供者与角色
账号资料中的「提供者」与「角色」是不同栏位：
| 概念 | 目前用途 | 不能推导出的结论 |
|---|---|---|
| 访客 | 没有持久登录身份，仍可在规则允许下发表部分评论 | 不代表可以 Reaction、查看管理资料或永久保留编辑权 |
| 读者 | 经有效会话验证的普通使用者 | 不代表拥有管理员权限或任何审核豁免 |
| 管理员 | 由服务端依据受信任身份与管理设置核验的站务角色 | 不代表可以在公开页面揭露读者私密资料 |
| Epomail 提供者 | 由受信任的 Epomail 流程提供身份信息 | 不代表任何同名或非受信任来源都能取得管理角色 |
| 本地提供者 | 开发或兼容流程中的本地读者身份 | 不会因名称或前端栏位而自动升级为管理员 |
目前账号 API 暴露 Epomail 与 local 两种登录模式；服务端会对角色做安全降级，未经受信任的管理核验不得取得 admin 角色。LV、TL、角色与徽章的差异，另见身份等级与徽章说明。
2. 登录与会话生命周期
成功登录或建立本地身份后，服务端会发出会话令牌，并在可用时将用户与会话保存到 D1；开发或没有数据库绑定的路径可能使用程序内存保存，这不是生产耐久性保证。
目前身份服务的代码设置会话有效期为 14 天。每次需要身份的 API 都应重新检查令牌与有效期；过期、撤销或无法核验的令牌不得继续用于账号资料、评论所有权、Reaction 或管理操作。若未来修改期限，应同步更新本页与测试。
浏览器端会为账号中心与评论组件保存必要的身份信息，以便在页面间同步显示；这些资料不是额外的权限来源。真正的用户资料与角色仍由服务端会话回查。
3. 登出、过期与失去所有权
- 使用账号中心登出时，客户端会清除本地身份资料，并请求服务端撤销会话；
- 会话自然过期或服务端找不到令牌时，账号 API 应返回未授权，前端不得继续假设已登录；
- 访客评论的临时 session token 只用于证明该浏览环境曾取得的留言所有权，重新刷新、切换浏览器、清除资料或失去令牌后可能无法编辑/删除；
- 无法证明所有权时，站方不会以昵称、头像或电子邮件的相似性代替有效鉴权；
- 怀疑账号被冒用时，不要用新账号反复尝试绕过限制，应先登出、保存必要时间点，再私下通报。
4. 权限如何被判定
服务端权限与身份的最低原则如下：
GET /api/auth/user与GET /api/auth/user-level需要有效会话令牌；- 一般读者只能查询自己的身份与等级资料，指定其他电子邮件查询属于管理范围；
- 评论编辑与删除需要留言所有权的有效 session token，或通过管理员验证；
- Reaction/Like 需要登录读者或管理员身份，访客不能以作者字段伪造登录；
- 管理员操作仍需使用服务端管理验证，不会因前端显示
admin徽章而自动成立。
具体字数、限流、公开字段与处置规则，请以评论与审核规范及当下服务端响应为准。
5. 个人资料与账号更新
账号可以包含名称、头像、网站、简介、时区与地区等字段。更新前请确认资料不冒充他人、不包含不必要的敏感信息，也不要把密码、令牌或支付资料写入简介与网站字段。
若需要查询、更正或删除账号资料，请参考隐私与资料使用说明并以原有账号或其他合理方式证明请求者身份。删除账号或登出不一定能立即移除已进入评论、备份、审计、财务核对或第三方通知的所有资料。
6. 问题回报
遇到无法登录、错误角色、会话反复失效或疑似未授权操作时，请提供发生时间、页面/API、浏览器、错误信息与不含敏感资料的复现步骤。不要提供完整令牌或密码；安全疑虑请改用安全问题通报规范。
最后更新：2026-10-20。
EpoCanvas Account and Session Security Guide
COMMUNITY-010 Account Governance Server-Side Priority
This page explains how account identities and sessions are utilized. It does not treat public names, LV/TL levels, badges, or browser-stored data as security permissions; actual permissions are determined by server-side verification.
[!WARNING] Session tokens are equivalent to short-term login credentials. Do not paste them into comments, Issues, screenshots, analytics tools, or third-party websites. If you suspect a token has been leaked, log out immediately and contact the site administrators via the Reporting and Appeals Guide.
1. Identity, Providers, and Roles
The “Provider” and “Role” fields in account data are distinct:
| Concept | Current Usage | What It Does Not Imply |
|---|---|---|
| Guest | No persistent login identity; can post certain comments if allowed by rules | Does not imply the ability to React, view administrative data, or retain permanent edit rights |
| Reader | A standard user verified via a valid session | Does not imply administrator privileges or any moderation exemptions |
| Administrator | A site staff role verified by the server based on trusted identity and admin settings | Does not imply the ability to disclose reader private data on public pages |
| Epomail Provider | Identity information provided by a trusted Epomail flow | Does not imply that any source with the same name or untrusted origin can obtain the admin role |
| Local Provider | Local reader identity in development or compatibility flows | Does not automatically upgrade to administrator based on name or frontend fields |
The current account API exposes two login modes: Epomail and local. The server performs security downgrading of roles; the admin role cannot be obtained without trusted administrative verification. For differences in LV, TL, roles, and badges, see the Identity Levels and Badges Guide.
2. Login and Session Lifecycle
After a successful login or local identity creation, the server issues a session token and, when available, saves the user and session to D1. Development paths or those without database bindings may use in-memory storage, which does not guarantee production durability.
The current identity service configuration sets the session validity period to 14 days. Every API requiring identity verification should re-check the token and its expiration; expired, revoked, or unverifiable tokens must not be used for account data, comment ownership, Reactions, or administrative operations. If the expiration period is modified in the future, this page and the tests should be updated accordingly.
The browser stores necessary identity information for the Account Center and comment components to facilitate synchronized display across pages; this data is not an additional source of permissions. Actual user data and roles are still retrieved via server-side session lookups.
3. Logout, Expiration, and Loss of Ownership
- When logging out via the Account Center, the client clears local identity data and requests the server to revoke the session;
- When a session naturally expires or the server cannot find the token, the account API should return unauthorized, and the frontend must not continue to assume the user is logged in;
- The temporary session token for guest comments is only used to prove ownership of comments acquired in that browsing environment; editing/deleting may become impossible after refreshing, switching browsers, clearing data, or losing the token;
- When ownership cannot be proven, the site will not substitute valid authentication with similarity in nicknames, avatars, or email addresses;
- If you suspect your account has been compromised, do not repeatedly attempt to bypass restrictions with a new account. Instead, log out, preserve necessary timestamps, and report the issue privately.
4. How Permissions Are Determined
The minimum principles for server-side permissions and identity are as follows:
GET /api/auth/userandGET /api/auth/user-levelrequire a valid session token;- General readers can only query their own identity and level data; querying other email addresses falls under administrative scope;
- Editing and deleting comments require a valid session token proving comment ownership, or administrator verification;
- Reactions/Likes require a logged-in reader or administrator identity; guests cannot forge login status using the author field;
- Administrative operations still require server-side administrative verification and are not automatically granted just because the frontend displays an
adminbadge.
For specific character limits, rate limiting, public fields, and enforcement rules, please refer to the Comments and Moderation Guidelines and the current server responses.
5. Personal Data and Account Updates
Accounts can include fields such as name, avatar, website, bio, timezone, and region. Before updating, ensure that the data does not impersonate others, does not contain unnecessary sensitive information, and does not include passwords, tokens, or payment data in the bio and website fields.
If you need to query, correct, or delete account data, please refer to the Privacy and Data Usage Guide and prove the requester’s identity using the original account or other reasonable methods. Deleting an account or logging out may not immediately remove all data that has already entered comments, backups, audits, financial reconciliations, or third-party notifications.
6. Issue Reporting
If you encounter login failures, incorrect roles, repeated session invalidations, or suspected unauthorized operations, please provide the time of occurrence, page/API, browser, error message, and reproduction steps that do not contain sensitive data. Do not provide full tokens or passwords; for security concerns, please use the Security Disclosure Guidelines.
Last updated: 2026-10-20.
Explication de la sécurité des comptes et des sessions EpoCanvas
COMMUNITY-010 Gestion des comptes Priorité côté serveur
Cette page explique comment l'identité du compte et la session sont utilisées. Elle ne considère pas le nom public, LV/TL, les badges ou une partie des données du navigateur comme des autorisations de sécurité ; les autorisations réelles sont déterminées par la validation côté serveur.
[!WARNING] Le jeton de session équivaut à un credential de connexion à court terme. Ne le collez pas dans les commentaires, les issues, les captures d’écran, les outils d’analyse ou les sites tiers. Si vous suspectez une fuite du jeton, déconnectez‑vous immédiatement et contactez l’équipe du site conformément aux Instructions de signalement et d’appel.
1. Identité, fournisseur et rôle
Dans les données du compte, le « fournisseur » et le « rôle » sont des champs distincts :
| Concept | Utilisation actuelle | Conclusion non déductible |
|---|---|---|
| Visiteur | Pas d’identité de connexion persistante, mais peut publier certains commentaires si les règles le permettent | Ne signifie pas que vous pouvez réagir, voir les données d’administration ou conserver indéfiniment les droits d’édition |
| Lecteur | Utilisateur ordinaire avec une session valide | Ne confère pas de droits d’administrateur ni d’exemptions de modération |
| Administrateur | Rôle de site vérifié par le serveur en fonction d’une identité de confiance et des paramètres d’administration | Ne signifie pas que vous pouvez divulguer des informations privées du lecteur sur une page publique |
| Fournisseur Epomail | Fournit les informations d’identité via le processus Epomail de confiance | Ne signifie pas que toute source du même nom ou non fiable peut obtenir le rôle d’administrateur |
| Fournisseur local | Identité de lecteur local dans les processus de développement ou de compatibilité | Ne passe pas automatiquement à administrateur en fonction du nom ou du champ front‑end |
L’API de compte expose actuellement deux modes de connexion : Epomail et local ; le serveur effectue une rétrogradation de sécurité des rôles, et aucune vérification d’administration de confiance ne permet d’obtenir le rôle admin. Pour les différences entre LV, TL, rôles et badges, voir égalementDescription des niveaux d’identité et des badges.
2. Connexion et cycle de vie de la session
Après une connexion réussie ou la création d’une identité locale, le serveur émet un jeton de session et, si possible, enregistre l’utilisateur et la session dans D1 ; les chemins de développement ou sans liaison de base de données peuvent utiliser la mémoire du processus pour le stockage, ce qui ne constitue pas une garantie de durabilité en production.
La configuration actuelle du service d’identité définit la durée de validité de la session à 14 jours. Chaque API nécessitant une identité doit vérifier à nouveau le jeton et sa date d’expiration ; les jetons expirés, révoqués ou non vérifiables ne doivent plus être utilisés pour les données du compte, la propriété des commentaires, les réactions ou les opérations d’administration. En cas de modification future de la durée, cette page et les tests doivent être mis à jour en conséquence.
Le côté navigateur conserve les informations d’identité nécessaires pour le centre de compte et les composants de commentaires afin de synchroniser l’affichage entre les pages ; ces données ne sont pas une source de permissions supplémentaire. Les vraies données utilisateur et les rôles sont toujours vérifiés par le serveur via la session.
3. Déconnexion, expiration et perte de propriété
- Lors de la déconnexion via le centre de compte, le client efface les données d’identité locales et demande au serveur de révoquer la session ;
- Lorsque la session expire naturellement ou que le serveur ne trouve pas le jeton, l’API du compte doit retourner une erreur d’authentification, et le frontend ne doit plus supposer que l’utilisateur est connecté ;
- Le jeton de session temporaire des commentaires des visiteurs sert uniquement à prouver la propriété des messages obtenus dans cet environnement de navigation ; après un rafraîchissement, un changement de navigateur, un effacement des données ou la perte du jeton, il peut devenir impossible de modifier/supprimer ;
- En l’absence de preuve de propriété, le site ne remplace pas l’authentification valide par la similarité du pseudonyme, de l’avatar ou de l’adresse e-mail ;
- En cas de suspicion d’usurpation de compte, n’essayez pas de contourner les restrictions en créant de nouveaux comptes ; déconnectez-vous d’abord, conservez les preuves nécessaires et signalez le problème en privé.
4. Détermination des permissions
Les principes minimaux des permissions et de l’identité côté serveur sont les suivants :
GET /api/auth/useretGET /api/auth/user-levelnécessitent un jeton de session valide ;- Les lecteurs ordinaires ne peuvent interroger que leurs propres données d’identité et de niveau ; l’interrogation d’autres adresses e-mail relève de l’administration ;
- La modification et la suppression de commentaires nécessitent un jeton de session valide prouvant la propriété du message, ou une vérification par un administrateur ;
- Les Réactions/Likes nécessitent un lecteur connecté ou un administrateur ; les visiteurs ne peuvent pas usurper la connexion via le champ de l’auteur ;
- Les opérations d’administration nécessitent toujours une vérification d’administration côté serveur et ne sont pas automatiquement validées par l’affichage du badge
adminsur le frontend.
Pour les règles spécifiques concernant le nombre de mots, la limitation de débit, les champs publics et les mesures disciplinaires, veuillez vous référer àles normes de commentaires et de modérationet aux réponses actuelles du serveur.
5. Données personnelles et mise à jour du compte
Le compte peut inclure des champs tels que le nom, l’avatar, le site web, la biographie, le fuseau horaire et la région. Avant de mettre à jour, veuillez vous assurer que les données n’usurpent pas l’identité d’autrui, ne contiennent pas d’informations sensibles inutiles et que vous n’inscrivez pas de mots de passe, de jetons ou de données de paiement dans les champs de biographie et de site web.
Si vous devez consulter, corriger ou supprimer les données de votre compte, veuillez consulterDescription de la confidentialité et de l’utilisation des donnéesEt utilisez le compte existant ou d’autres moyens raisonnables pour prouver l’identité du demandeur. Supprimer le compte ou se déconnecter ne garantit pas l’effacement immédiat de toutes les données déjà entrées dans les commentaires, sauvegardes, audits, vérifications financières ou notifications tierces.
6. Rapport de problème
En cas d’incapacité de connexion, de rôle incorrect, d’invalidation répétée de la session ou de suspicion d’opération non autorisée, veuillez fournir l’heure de l’incident, la page/API, le navigateur, le message d’erreur et les étapes de reproduction sans données sensibles. Ne fournissez pas le jeton complet ou le mot de passe ; en cas de préoccupations de sécurité, utilisez plutôtNormes de signalement des problèmes de sécurité。
Dernière mise à jour : 2026-10-20.
EpoCanvas Explicación de la seguridad de cuentas y sesiones
COMMUNITY-010 Gobernanza de cuentas Prioridad del servidor
Esta página explica cómo se utilizan la identidad de la cuenta y la sesión. No considera el nombre público, LV/TL, insignias o una sección de datos en el navegador como permisos de seguridad; los permisos reales se basan en la verificación del servidor.
[!WARNING] El token de sesión es equivalente a un certificado de inicio de sesión a corto plazo. No lo pegues en comentarios, Issues, capturas de pantalla, herramientas de análisis o sitios de terceros. Si sospechas que el token se ha filtrado, cierra sesión inmediatamente y contacta al sitio siguiendo las instrucciones de reporte y apelación.
1. Identidad, proveedor y rol
En los datos de la cuenta, ‘proveedor’ y ‘rol’ son campos diferentes:
| Concepto | Uso actual | Conclusiones que no se pueden derivar |
|---|---|---|
| Visitante | No tiene una identidad de inicio de sesión persistente, pero aún puede publicar ciertos comentarios según las reglas permitidas | No significa que pueda reaccionar, ver datos de administración o mantener permanentemente el derecho de edición |
| Lector | Usuario normal con sesión válida | No implica tener privilegios de administrador ni ninguna exención de revisión |
| Administrador | Rol de servicio verificado por el servidor basado en identidad confiable y configuración de administración | No significa que pueda revelar datos privados de lectores en páginas públicas |
| Proveedor de Epomail | Información de identidad proporcionada por el proceso confiable de Epomail | No implica que cualquier persona con el mismo nombre o fuente no confiable pueda obtener el rol de administrador |
| Proveedor local | Identidad de lector local en procesos de desarrollo o compatibles | No se convierte automáticamente en administrador por el nombre o los campos del frontend |
La API de cuentas actual expone dos modos de inicio de sesión: Epomail y local; el servidor degradará la seguridad de los roles, y la verificación de administración no confiable no puede obtener el rol admin. Para más detalles sobre las diferencias entre LV, TL, roles y insignias, consulteDescripción de niveles de identidad y insignias.
2. Inicio de sesión y ciclo de vida de la sesión
Después de iniciar sesión con éxito o crear una identidad local, el servidor emitirá un token de sesión y, cuando sea posible, guardará al usuario y la sesión en D1; los entornos de desarrollo o los caminos sin enlace a base de datos pueden usar la memoria del proceso para guardarlo, lo cual no garantiza durabilidad en producción.
Actualmente, el código del servicio de identidad establece la validez de la sesión en 14 días. Cada API que requiera identidad debe volver a verificar el token y su validez; los tokens expirados, revocados o que no puedan verificarse no deben usarse para datos de cuenta, propiedad de comentarios, reacciones o acciones de administración. Si se modifica el plazo en el futuro, se debe actualizar esta página y las pruebas en sincronía.
El cliente del navegador guardará la información de identidad necesaria para el centro de cuentas y los componentes de comentarios, para que se muestre de forma sincronizada entre páginas; estos datos no son una fuente adicional de permisos. Los datos reales del usuario y sus roles siguen siendo consultados por la sesión del servidor.
3. Cierre de sesión, expiración y pérdida de propiedad
- Al cerrar sesión mediante el centro de cuentas, el cliente eliminará los datos de identidad locales y solicitará al servidor revocar la sesión;
- Cuando la sesión expira naturalmente o el servidor no encuentra el token, la API de cuentas debe devolver no autorizado, y el frontend no debe seguir asumiendo que está conectado;
- El token de sesión temporal de los comentarios de visitantes solo sirve para demostrar que el entorno de navegación obtuvo la propiedad del comentario; al recargar, cambiar de navegador, borrar datos o perder el token, puede que no sea posible editar/eliminar;
- Si no se puede demostrar la propiedad, el sitio no sustituirá la autenticación válida por similitudes en apodo, avatar o correo electrónico;
- Si sospechas que una cuenta ha sido usurpada, no intentes evadir las limitaciones con una cuenta nueva; primero cierra sesión, guarda los momentos necesarios y reporta de forma privada.
4. Cómo se determinan los permisos
Los principios mínimos de permisos e identidad del servidor son los siguientes:
GET /api/auth/useryGET /api/auth/user-levelrequieren un token de sesión válido;- Los lectores normales solo pueden consultar su propia información de identidad y nivel; consultar otro correo electrónico está dentro del ámbito de la administración;
- Editar o eliminar comentarios requiere un token de sesión válido que demuestre la propiedad del mensaje, o la verificación de un administrador;
- Reacción/Me gusta requiere que el lector o administrador haya iniciado sesión; los visitantes no pueden falsificar el inicio de sesión mediante el campo de autor;
- Las acciones de administrador aún requieren la verificación de gestión del servidor; no se conceden automáticamente solo porque la interfaz muestre la insignia
admin;
Para detalles sobre recuento de palabras, limitación de velocidad, campos públicos y reglas de manejo, consultelas normas de comentarios y moderacióny la respuesta actual del servidor.
5. Actualización de perfil y cuenta
Una cuenta puede incluir campos como nombre, avatar, sitio web, biografía, zona horaria y región. Antes de actualizar, asegúrese de que la información no suplantará a otros, no contenga datos sensibles innecesarios, y no incluya contraseñas, tokens o datos de pago en la biografía o el campo del sitio web.
Si necesita consultar, corregir o eliminar datos de la cuenta, consulteAviso de privacidad y uso de datosY demuestre la identidad del solicitante con la cuenta existente u otro método razonable. Eliminar la cuenta o cerrar sesión no necesariamente elimina inmediatamente todos los datos que ya han sido incluidos en comentarios, copias de seguridad, auditorías, conciliaciones financieras o notificaciones a terceros.
6. Reporte de problemas
Si encuentra problemas de inicio de sesión, roles incorrectos, sesiones que expiran repetidamente o sospecha de operaciones no autorizadas, proporcione la hora del incidente, la página/API, el navegador, el mensaje de error y los pasos para reproducir sin incluir datos sensibles. No proporcione tokens completos ni contraseñas; si tiene preocupaciones de seguridad, useDirectrices para la notificación de problemas de seguridad.
Última actualización: 2026-10-20.
EpoCanvas: Konten- und Sitzungssicherheit
COMMUNITY-010 Kontenverwaltung Serverseitig priorisiert
Diese Seite erklärt, wie Kontenidentitäten und Sitzungen verwendet werden. Öffentliche Namen, LV/TL-Stufen, Abzeichen oder Daten im Browser werden nicht als Sicherheitsberechtigungen betrachtet; die tatsächlichen Berechtigungen basieren auf der serverseitigen Verifizierung.
[!WARNING] Sitzungstokens sind gleichwertig mit kurzfristigen Anmeldeinformationen. Füge sie niemals in Kommentare, Issues, Screenshots, Analysetools oder auf Drittanbieter-Websites ein. Wenn du den Verdacht hast, dass ein Token kompromittiert wurde, melde dich sofort ab und kontaktiere das Team über die Richtlinien für Meldungen und Beschwerden.
1. Identität, Anbieter und Rollen
„Anbieter” und „Rolle” sind in den Kontendaten separate Felder:
| Konzept | Aktueller Zweck | Was daraus nicht abgeleitet werden kann |
|---|---|---|
| Gast | Keine persistente Login-Identität, kann jedoch unter bestimmten Regeln teilweise kommentieren | Keine Berechtigung für Reaktionen, Zugriff auf Verwaltungsdaten oder dauerhafte Bearbeitungsberechtigungen |
| Leser | Normaler Benutzer mit gültiger Sitzungsverifizierung | Keine Administratorrechte oder Befreiung von der Moderation |
| Administrator | Rollenbasierte Funktion, die serverseitig anhand vertrauenswürdiger Identität und Verwaltungseinstellungen verifiziert wird | Keine Berechtigung, private Daten von Lesern auf öffentlichen Seiten preiszugeben |
| Epomail-Anbieter | Identitätsinformationen, die über einen vertrauenswürdigen Epomail-Prozess bereitgestellt werden | Nicht jeder gleichnamige oder nicht vertrauenswürdige Anbieter erhält automatisch Administratorrechte |
| Lokaler Anbieter | Lokale Leseridentität in Entwicklungs- oder Kompatibilitätsprozessen | Wird nicht aufgrund des Namens oder von Frontend-Feldern automatisch zum Administrator |
Die aktuelle Konten-API unterstützt zwei Login-Modi: Epomail und lokal. Der Server führt eine sichere Herabstufung der Rollen durch; die Rolle admin kann nur nach einer vertrauenswürdigen Verifizierung durch die Verwaltung erteilt werden. Zu den Unterschieden zwischen LV, TL, Rollen und Abzeichen siehe die Erklärung zu Identitätsstufen und Abzeichen.
2. Login und Sitzungslebenszyklus
Nach einem erfolgreichen Login oder der Erstellung einer lokalen Identität stellt der Server ein Sitzungstoken aus und speichert Benutzer und Sitzung, wenn möglich, in D1. In Entwicklungsumgebungen oder bei fehlender Datenbankbindung kann der Prozessspeicher verwendet werden; dies stellt jedoch keine Garantie für die Persistenz in der Produktion dar.
Die aktuelle Konfiguration des Identitätsdienstes legt die Gültigkeitsdauer der Sitzung auf 14 Tage fest. Jede API, die eine Identität erfordert, muss das Token und dessen Ablaufzeitpunkt erneut überprüfen. Abgelaufene, widerrufene oder nicht verifizierbare Tokens dürfen nicht für Kontendaten, Kommentarbesitz, Reaktionen oder Verwaltungsvorgänge verwendet werden. Bei zukünftigen Änderungen der Fristen müssen diese Seite und die Tests entsprechend aktualisiert werden.
Der Browser speichert die erforderlichen Identitätsinformationen für das Kontenzentrum und die Kommentar-Komponente, um eine konsistente Anzeige über verschiedene Seiten hinweg zu gewährleisten. Diese Daten stellen keine zusätzliche Berechtigungsquelle dar. Die tatsächlichen Benutzerdaten und Rollen werden weiterhin durch die serverseitige Sitzung abgerufen.
3. Abmeldung, Ablauf und Verlust des Besitzes
- Bei der Abmeldung über das Kontenzentrum werden die lokalen Identitätsdaten gelöscht und der Server um die Widerrufung der Sitzung gebeten;
- Wenn eine Sitzung abläuft oder der Server das Token nicht findet, sollte die Konten-API „nicht autorisiert” zurückgeben; das Frontend darf nicht davon ausgehen, dass der Benutzer weiterhin angemeldet ist;
- Das temporäre Sitzungstoken für Gastkommentare dient nur dem Nachweis des Besitzes eines Kommentars in dieser spezifischen Browserumgebung. Nach einem Neuladen, einem Browserwechsel, dem Löschen von Daten oder dem Verlust des Tokens kann der Kommentar möglicherweise nicht mehr bearbeitet oder gelöscht werden;
- Wenn der Besitz nicht nachgewiesen werden kann, ersetzt die Verwaltung den gültigen Authentifizierungsnachweis nicht durch Ähnlichkeiten in Spitznamen, Avataren oder E-Mail-Adressen;
- Wenn du den Verdacht hast, dass dein Konto missbraucht wird, versuche nicht, Beschränkungen mit einem neuen Konto zu umgehen. Melde dich zuerst ab, sichere relevante Zeitstempel und melde den Vorfall vertraulich.
4. Wie Berechtigungen geprüft werden
Die grundlegenden Prinzipien für serverseitige Berechtigungen und Identitäten lauten wie folgt:
GET /api/auth/userundGET /api/auth/user-levelerfordern ein gültiges Sitzungstoken;- Normale Leser können nur ihre eigenen Identitäts- und Stufendaten abfragen; die Abfrage anderer E-Mail-Adressen fällt in den Verwaltungsbereich;
- Das Bearbeiten und Löschen von Kommentaren erfordert ein gültiges Sitzungstoken für den Kommentarbesitz oder eine Verifizierung durch einen Administrator;
- Reaktionen/Likes erfordern eine angemeldete Leser- oder Administratoridentität; Gäste können sich nicht über das Autorenfeld als angemeldet ausgeben;
- Verwaltungsvorgänge erfordern weiterhin eine serverseitige Verifizierung; die Anzeige eines
admin-Abzeichens im Frontend verleiht keine automatischen Rechte.
Für konkrete Zeichenlimits, Rate-Limiting, öffentliche Felder und Sanktionsregeln gelten die Richtlinien für Kommentare und Moderation sowie die aktuellen serverseitigen Antworten.
5. Persönliche Daten und Kontenaktualisierung
Ein Konto kann Felder wie Name, Avatar, Website, Kurzbeschreibung, Zeitzone und Region enthalten. Stelle vor der Aktualisierung sicher, dass die Daten niemanden vortäuschen, keine unnötigen sensiblen Informationen enthalten und keine Passwörter, Tokens oder Zahlungsdaten in die Kurzbeschreibung oder das Website-Feld eingetragen werden.
Für die Abfrage, Korrektur oder Löschung von Kontendaten siehe die Erklärung zu Datenschutz und Datennutzung. Bitte weise deine Identität über das ursprüngliche Konto oder auf andere angemessene Weise nach. Die Löschung eines Kontos oder die Abmeldung führt nicht unbedingt zur sofortigen Entfernung aller Daten, die bereits in Kommentaren, Backups, Audit-Logs, Finanzabrechnungen oder Benachrichtigungen an Dritte enthalten sind.
6. Fehlermeldungen
Wenn du dich nicht anmelden kannst, eine falsche Rolle zugewiesen bekommst, die Sitzung wiederholt abläuft oder verdächtige nicht autorisierte Aktionen feststellst, bitte um Angabe von Zeitpunkt, betroffener Seite/API, Browser, Fehlermeldung und einer Reproduktionsanleitung ohne sensible Daten. Bitte keine vollständigen Tokens oder Passwörter bereitstellen. Für Sicherheitsbedenken nutze bitte die Richtlinien für die Meldung von Sicherheitslücken.
Zuletzt aktualisiert: 2026-10-20.
