Framework7移动Web应用：基于WebApi的登录与会话维护方案咨询

• 仅存储用户名到localStorage的思路有一定合理性：不涉及密码等敏感信息，确实降低了本地存储泄露的风险，适配移动设备场景的基础安全需求，且实现成本低，能快速搭建自动登录的基础流程。

• 会话状态不一致：仅存储用户名的话，后端无法校验用户会话是否已过期、注销或被禁用。比如用户在其他设备注销账号，当前设备仍能通过本地存储的用户名自动登录，导致前后端会话状态脱节。
• 本地存储可篡改：localStorage为明文存储，用户可手动修改存储的用户名，若后端无额外校验逻辑，会存在冒充其他用户登录的风险。
• 缺乏有效认证凭证：ASP.Net的FormsAuthentication.SetAuthCookie本质是生成加密的认证Cookie，后端可校验凭证合法性与有效期。而当前方案仅靠用户名自动登录，要么需要后端做免密登录逻辑（风险极高），要么后端直接信任用户名，存在明显安全漏洞。

在全局page:init函数中检查会话并执行自动登录是可行的，但需注意以下细节：

• 防止重复请求：添加全局状态标记（如isAutoLoggingIn），避免多页面初始化时重复触发自动登录逻辑。
• 优化用户体验：自动登录过程中显示加载提示，避免用户误以为应用无响应。
• 异常处理：若自动登录失败（如用户名无效、会话已失效），及时清除localStorage中的用户名，引导用户进入登录页面。

• 存储后端签发的加密认证凭证：比如JWT Token或ASP.Net生成的签名认证Ticket，凭证包含用户名、过期时间等信息，后端可校验凭证合法性，避免本地存储用户名带来的冒充问题。
• 选择合适的存储方式：若无需跨浏览器会话持久化，可使用sessionStorage替代localStorage，sessionStorage在浏览器关闭后自动清除，安全性更高。
• 自动登录流程优化：自动登录时携带存储的认证凭证到后端校验，校验通过后再恢复用户会话，而非直接根据用户名登录。

内容的提问来源于stack exchange，提问作者Abbas