如何在REST API中区分移动端应用用户与Web端应用用户？

基础角色访问规则 #

系统共设4类用户角色，端访问权限边界如下：

• Coach（教练）：仅可使用移动端应用
• Athlete（运动员）：仅可使用移动端应用
• Meet Director（赛事主管）：可同时使用移动端、Web端应用
• Admin（管理员）：仅可使用Web端应用

适用Gem工具推荐 #

基于Rails技术栈的话，选以下几个成熟工具就能覆盖全部需求，不需要从零造轮子：

• devise：Rails生态最通用的身份认证基础框架，自带会话管理、密码找回、账号锁定等基础能力，同时支持扩展适配API认证场景
• pundit：轻量权限控制工具，权限逻辑按资源维度封装在独立Policy类中，不会出现权限判断散落在控制器、视图、路由各处难以维护的问题，非常适合做「角色+访问端」双维度的细粒度权限校验
• devise-jwt：devise的JWT认证扩展，专门给移动端API场景做无状态Token认证，不需要服务端存储会话，适配移动端APP前后端分离的请求特性
• rolify（可选）：如果后续需要动态调整角色、给单个用户分配多个角色，可以用这个工具做角色关联管理，不需要在用户表硬编码角色枚举字段，扩展性更好

具体落地实现思路 #

1. 数据层设计
   直接在users核心用户表加role字段，用枚举类型存储4类角色即可，不需要为不同角色建独立用户表，避免数据冗余。如果用rolify则不需要加该字段，通过角色关联表给用户分配对应角色即可。可额外加last_login_client字段记录用户最后登录的端类型，方便做异常登录风控。
2. 路由层前置拦截
   路由按端拆成两个独立命名空间：/api/v1/mobile 下挂载全部移动端接口，/web 下挂载全部Web端路由。在路由层加请求约束，直接拦截越权访问的请求：比如访问/web下路由的请求，如果识别到用户角色是Coach/Athlete直接返回403；访问移动端接口的请求如果识别到角色是Admin直接拦截，从入口层挡住非法请求，减少后续控制器层的无效处理。
3. 认证逻辑分端适配
   Web端走devise默认的Cookie会话认证，开启CSRF防护，和普通Web应用认证逻辑一致；移动端走devise-jwt的JWT Token认证，用户移动端登录成功后签发固定有效期的Token，后续请求放在请求头中携带校验，服务端不存储会话，适配移动端的使用场景。Meet Director类用户不需要单独建两个账号，从哪个端发起登录请求，就对应下发哪种认证凭证即可。
4. 业务层细粒度权限校验
   用pundit为每个业务资源编写对应Policy类，校验逻辑同时覆盖两个维度：当前用户的角色、当前请求所属的客户端类型。比如赛事编辑权限的判断逻辑：仅Meet Director、Admin有编辑权限，其中Admin只有从Web端发起请求才放行，Meet Director从移动端、Web端发起请求都允许操作。
5. 端侧登录前置提示
   Web端登录页、移动端APP登录页提前做账号类型校验：Web端提交登录时如果识别到账号是Coach/Athlete，直接提示「该账号仅支持移动端APP登录」；移动端提交登录时如果识别到账号是Admin，直接提示「该账号仅支持Web管理后台登录」，减少无效的服务端请求。

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