Portal 认证系统要接的设备从来不整齐。同一栋楼里可能同时跑着几年前的老接入设备和新换的无线控制器，品牌不同、固件不同、能力也不同。产品资料里把支持的对接方式写得很清楚：华为 Portal 1.0 和 2.0、移动的 CMCC 协议、标准 Radius 规范，以及任意使用 HTTP 提交等方式的 NAS 设备。前三句大家熟悉，最后那一句才是很多老项目能接进来的原因。它意味着设备即使不会跑标准协议，只要能按约定的方式把参数递过来，也有机会纳入同一套认证。
先分清设备属于哪一类
对接之前第一步不是打开配置界面，而是给现网设备分类。第一类能跑标准协议，认证、授权、下线这些动作都能正常完成，这类设备按常规方式接即可。第二类不支持标准协议，但支持按约定的格式提交请求，也就是资料里说的 HTTP 提交方式，这类设备可以接，只是能力上有缺口。第三类既不支持标准协议，也没有可用的提交接口，这类设备无论怎么配置都接不进来，只能换设备或者在链路上增加可控的网关。分类这一步必须在勘测阶段做完，不能等到实施时才发现。
HTTP 提交方式解决的是什么问题
它的思路很直白：设备不参与复杂的协议交互，而是在用户需要上网时，把能拿到的参数按约定组装成一个请求发给认证平台，平台判断这个用户能不能放行，再把结果回给设备，设备据此放通或者拦住。对用户来说体验没有区别，一样是弹出页面、填信息、通过后上网。差别在背后：这种方式把判断权集中到了平台侧，设备只需要能发请求和接收结果，对设备本身的能力要求低得多。
它和标准协议比少了什么
代价是有的，而且主要出在反向动作上。认证通过只是第一步，后面还有强制下线、动态调整限速、按时长到期自动断开这类需要平台主动通知设备的动作。标准协议下这些动作有成熟的通道，走提交方式的链路往往只能完成请求和应答这一段，反向的动作能不能生效、生效得及不及时，取决于设备侧到底提供了什么能力。很多项目上线后发现的怪现象，比如点了下线用户还在上网，根子就在这里。
对接前要把字段一项项对清
提交方式能不能跑通，八成取决于字段。设备侧能提交哪些：用户拿到的地址、终端的网卡地址、接入设备的标识、用户连的是哪个无线信号，这些字段缺一个，平台侧的策略就少一个判断依据。平台侧需要哪些也要提前列出来，两边对不上就要么改设备配置，要么在平台侧做兼容。字段名、编码方式、大小写、有没有多余空格，这些细节看着琐碎，实际是联调时最花时间的地方。
字段对不上的典型后果
字段缺失不会让认证直接失败，它会让认证看起来成功、实际上半通。缺少终端标识，多终端限制和账号共享识别就失去依据；缺少接入设备标识，分区域分设备的策略推不下去；缺少无线信号标识，不同人群走不同认证页的设计就落空。这类半通状态最麻烦的地方在于，上线时测几个人都正常，跑一段时间才暴露，而排查时大家习惯去查认证逻辑，很少想到是字段没传上来。
为什么必须在勘测阶段真机试一次
老设备的文档和实际行为经常不一致。文档写着支持某种提交方式，实际抓出来发现少两个字段；或者参数顺序和示例不同；或者设备在高负载下会省略可选字段。这些只有在真机上发一次请求才能看到。所以勘测时应该带着平台侧的人一起，让设备真实发一次请求，把平台收到的内容原样记下来，对照需求清单逐项确认。这一步花的时间，比实施到一半再返工要少得多。
超时和重试要单独设计
提交方式依赖的是一条普通的网络请求，网络一抖请求就慢，慢到超过等待窗口，用户看到的就是认证失败。所以超时时间要按实际链路质量来设，不能照抄默认值；同时要有重试机制，但不能无限重试，重试太多次会把平台的连接占满，本来只是个别慢请求，最后变成大面积失败。比较稳妥的做法是设一个有限次数的重试，重试之间留间隔，并且把失败请求计入监控，让运维能看见失败在涨。
安全边界不能顺手放过
既然放行与否由平台的一个应答决定，就要防止这个请求被伪造。设备侧提交请求的地址要在平台侧做来源限制，不是谁都能往这个地址发请求；提交内容要有校验，防止被篡改后冒用他人身份；请求和应答尽量走加密通道，避免在同一网段里被人截获后复用。这些措施不是额外加分项，而是提交方式成立的前提，少了它们，这套对接方式反而会成为一个更容易被绕过的口子。
验收时怎么验才算过
验收不能只看页面能打开、账号能登录。要至少验四件事：正常用户能认证通过并且拿到正确的策略；被拒绝的用户确实上不了网；管理员执行强制下线后终端真的断开；策略变更之后新认证的用户拿到的是新策略。第四项最容易被漏掉，但它能一次性验证反向通道是不是通的。每验一项都要在认证记录里留痕，事后才能对得上到底是哪个环节没生效。
什么时候应该换设备而不是硬接
能接不等于该接。判断的依据是把两边的账摆在一起：一边是硬接之后长期要付出的代价，包括缺失的能力、反复出现的小故障、每次排查要多花的时间；另一边是换设备或者调整链路的一次性投入，以及它对现网的影响。如果项目本身要求的能力很完整，而这批设备只能完成最基础的放行，那么硬接出来的系统会长期处于半通状态，运营越久越难受。这类取舍要早点摊开谈，别等到上线之后靠定制去补，那时候能选的路反而更少。