酒店无线Portal认证输错几次，系统该不该把人锁住
酒店无线Portal认证上线之后，前台和网络维护人员每天都会碰到一类问题：客人连着WiFi，认证页面也弹出来了，可就是过不去。要么房间号输错了，要么验证码看漏了一位，要么密码里的大小写没分清。客人急，操作的人也跟着急。这时候如果系统突然提示"尝试次数过多，请稍后再试"，场面往往更难收拾。问题就来了：酒店无线Portal认证输错几次，系统到底该不该把人锁住？
这个问题的答案不是简单的是或否，它牵扯到认证系统的安全逻辑和酒店场景里真实的用户体验。酒店不是一个内部系统，它面对的是形形色色的住客，认证失败的触发原因里，误操作占的比重远比恶意尝试大。所以锁定策略的设计，必须在防滥用和保体验之间找到一个平衡点。
频繁输错，到底意味着什么
认证失败次数激增，在酒店场景里通常有几种可能。最常见的是误操作：客人第一次用房间号认证，不知道自己该输哪几位，输错一两次很正常；短信验证码有时效，过期了再输，也算一次失败。另一种是输入习惯问题，比如把数字和字母弄混、全角半角没切换。这些都属于正常范围内的波动，不该被当成异常。
但也确实存在需要警惕的情况。比如有人拿着认证页面反复尝试不同的号码，试图猜出别人的上网凭证；又比如同一终端在短时间内提交大量请求，想把认证接口当成一个可以试探的入口。这种情况下，如果不做任何限制，认证系统就变成了一个可以被反复试探的目标，安全隐患是实打实的。日志里如果出现某个来源的认证失败次数异常高，就应该引起注意。
问题在于，酒店的前台和客人往往分不清眼前这个失败到底是误操作还是恶意尝试。系统如果一刀切，输错三次就锁定半小时，客人可能只是手滑了一下，就被晾在门外，投诉自然就来了。可要是不设任何限制，安全又没保障。所以关键不是"要不要锁定"，而是"怎么锁定才合理"。
锁定策略应该怎么设计
合理的做法，是把限制设计成可以区分场景的规则，而不是一个死板的次数门槛。比如针对同一个账号、同一个终端、同一个来源IP，分别设置不同的失败容忍度；短时间内的连续失败触发限制，时间拉长之后自动恢复正常；验证码类认证的失败次数和账号密码类认证的失败次数，也可以分开统计。这些参数在认证系统后台都是可以配置的，酒店可以根据自己的客群特点去调，而不是把别人的配置照搬过来。
锁定之后的处理路径也要提前想好。客人被锁了，得有人能把他放出来。酒店无线Portal认证系统支持后台管理，前台或者网络维护人员可以查询认证记录，确认是误操作之后给客人重置、解锁。锁定的时长不宜过长，短时间的临时锁定配合后台手动解锁，比把客人晾上几个小时要合理得多。设置阈值的时候还要考虑一个现实：酒店入住的客人流动性大，一个账号对应一段入住周期，锁定策略的时间尺度应该和入住周期匹配，而不是按内部员工的账号习惯来定。
同时，锁定策略不能只堵不疏。认证页面上应该把失败原因提示清楚——是房间号不对，还是验证码过期，还是账号被锁定。客人看得懂提示，才能自己纠正，而不是反复瞎试。提示越清楚，误操作越少，真正需要触发的锁定也就越少。
锁定的本质是保护，不是惩罚
把锁定策略想清楚之后会发现，它的目的从来不是给客人添堵，而是保护认证系统不被滥用，也保护住客凭证的安全。一个设计得当的锁定规则，正常客人几乎感受不到它的存在，因为大多数客人不会连续输错那么多次；真正被它拦住的，是那些不该被放行的试探。反过来，如果系统不做任何限制，表面上对客人很"宽容"，实际上把所有人的凭证都置于可以被反复试探的风险里，那才是更大的问题。
落地的时候，任何次数阈值、锁定时长这类参数，都不是一个放之四海而皆准的数字。它跟酒店的客群构成、入住率、认证方式都有关系，需要通过实际运营数据去调。一开始设得宽松一点，观察日志里认证失败的真实分布，再逐步收紧或放宽，比拍脑袋定一个数更稳妥。认证系统的日志里就记录着这些数据，把失败次数、失败原因、锁定触发情况拉出来看看，调整策略就有依据了。
所以回到开头那个问题：酒店无线Portal认证输错几次，系统该不该把人锁住？该锁，但要锁得有分寸。次数阈值可以配，锁定时长可以调，解锁通道必须留，失败提示必须清。把这几件事做对，认证系统既挡得住试探，也误伤不了住客。