万博登录页面

万博的登录页，第一眼看上去就是页面个普通的输入框加按钮。但你要是登录真拿它当普通表单看，那就掉坑里了。页面我头回打开的登录时候，F12 一按，页面好家伙，登录光登录相关的页面 JS 就压了六个文件，还没算上异步加载的登录那一堆。

页面结构本身倒不复杂。页面一个 <form> 包着账号、登录密码、页面验证码三个输入框，登录下面挂个“登录”按钮，页面旁边塞了个“记住我”的登录复选框。视觉上没什么花哨的，深色背景配金色描边，典型的博彩类站点审美。但你要是把鼠标移到按钮上，会发现那个 hover 动画不是 CSS 写的——是 JS 动态改的 transform 值，每帧都在算。

我扒了一下它的网络请求。账号框失焦的瞬间，浏览器会偷偷往一个 /api/check_user 的接口发个 POST，带上一串加密后的用户名。返回的 JSON 里有个 exist 字段，true 或 false。这意味着什么？意味着你还没点登录，它已经知道你这个账号存不存在了。密码框那边更绝，每次 keyup 事件都会触发一次本地加密，用的是 Web Crypto API 里的 SHA-256，加盐值硬编码在 JS 里，我拉出来一看，盐是 "wb_2023_salt_#!@"。这玩意儿防不了中间人，但能防住那些直接抓明文密码的脚本小子。

验证码那块更有意思。表面上是四个歪歪扭扭的字母，点一下能刷新。但刷新按钮绑定的不是重新请求图片，而是直接在前端用 Canvas 重绘。字符集就 24 个字母，去掉了容易混淆的 I、O、0、1。我抓了十次验证码，发现它有个隐藏规律：每次刷新后的正确答案，其实就藏在页面某个 data-* 属性里，只是做了 base64 反转。这设计挺偷懒的，但确实能拦住那些只会用 OCR 的初级脚本。

说句实在话，这种登录页的安全策略属于“防君子不防小人”。真正的攻击者直接绕开前端，拿代理池怼接口就完了。但万博这套东西至少把门槛抬到了需要懂点逆向的水平。

还有个细节值得提一嘴。登录按钮的点击事件里，有一段防抖逻辑写得特别糙——用的是 setTimeout 加全局标志位，而不是 debounce 函数。结果就是如果你手速够快，连点五下，它会发出去三个请求，后两个因为 token 过期直接被拒。我试过用脚本模拟每秒 20 次点击，页面直接卡死，控制台报了一堆 Uncaught (in promise) DOMException。这要是在真实用户手里，网络稍微抖一下，体验就稀碎。

页面底部藏了个 <noscript> 标签，里面写了句“请启用 JavaScript 以继续”。但如果你真把 JS 禁了，会发现那个登录按钮的 type 是 button 而不是 submit，表单压根不会提交。也就是说，这页面离了 JS 就是块死砖。我见过不少站点会做渐进增强，万博这边完全没考虑，估计也没打算考虑。

最后说个让我愣了一下的地方。登录成功的回调里，它没有直接跳转，而是先往 localStorage 塞了个 wb_token，然后调了个 window.location.replace。但那个 token 的过期时间写的是 Date.now() + 86400000 * 7，也就是七天。可服务端返回的 token 实际有效期只有两小时。这就导致一个奇葩现象：你登录后关掉页面，过三小时再打开，前端以为你还登录着，欢天喜地地往内页跳，结果被服务端一脚踢回登录页。用户看到的就是“刚登录完又要登”，骂娘的心都有了。

反正我扒完这一圈，最大的感受是：这页面能跑起来，全靠后端接口在兜底。前端代码里到处都是补丁摞补丁的痕迹，像是三拨人先后接手过，谁也没把前任的坑填干净。你要是想仿一个类似的登录页，别学它的状态管理，学学它的接口防抖和加密思路就行。别的，真没啥好抄的。