异地登录

概念解释

指网站或 APP 用户在不同地点登录到系统的行为。判断异地一般会使用用户登录 IP 地址作为参考标准,对于 APP 可以通过接入移动数据网络的位置定位到具体城市,所以 APP 采用的判定更加符合异地的定义。但对于网站来说,IP 地址判断是最简单也最可行对的方案了。

检测和实现逻辑

主要实现逻辑

  • 用户每次登录后添加一条登录记录,存放 IP 地址、登录时间等信息(没有做登录记录的,也可以将 IP 信息直接更新到用户表记录中)
  • 在登录用户的每次请求中(校验过用户登录状态后),检测当前登录 IP 是否与上次登录 IP 一致,根据后台配置决定是否结束当前的登录状态。如果后台配置禁止异地登录,立即结束当前的登录状态,并在前端提示用户存在异地登录情况,当前登录状态失效,需要重新登录,提示用户非本人登录须修改登录密码
  • 『非必要』用户可以查看不同 IP 地址的登录记录,选择禁止某些 IP 登录
  • 『非必要』用户每次登录后(账号密码已通过验证),检测当前登录 IP 是否与上次登录 IP 一致,不一致,返回前端添加额外的验证码,增加上一条的禁用 IP 登录判断

主要涉及到的表

用户登录记录表(或者用户表)、用户登录禁用 IP 记录表(非必要)

唯一登录

概念解释

指网站或 APP 用户只允许存在唯一一个登录状态。唯一登录不强调异地,只要有新的登录状态,旧的登录状态就会被关闭。用户的登录状态一般是保存在 session 中的,所以要实现唯一登录就相当于唯一 session。

检测和实现逻辑

主要实现逻辑

  • 用户每次登录后根据用户名添加一条(或更新)session 记录,保存用户名、session ID、登录设备(设备类型)、登录 IP、登录时间等信息
  • 在登录用户的每次请求中(校验过用户登录状态后),检测当前用户 session ID 是否与上次登录用户的 session ID 一致,根据后台配置决定是否结束当前的登录状态。如果后台配置唯一登录,立即结束当前的登录状态,并在前端提示系统设置用户唯一登录,当前用户已在其他地方登录,当前登录状态失效,需要重新登录,提示用户非本人登录须修改登录密码
  • 『非必要』可以将用户名和登录设备作为主键,这样可以将判断条件放宽到允许单个用户在不同设备上唯一登录。如果不需要这一步,session 记录表中的登录设备字段也可以去掉
  • 『非必要』存在登录设备,用户自然就可以管理登录设备。可以选择禁止某些设备登录,然后在用户每次登录后判断当前登录设备是否被禁止。

因为 web 端无法获取设备号和设备名称,而设备类型判断比较比较粗犷(Android,iOS,Mac,Windows...),所以如果存在多部相同类型的手机(如苹果手机),也只能登录一部

不同设备的唯一登录参考了微信账号与安全中的登录设备管理,可能因为微信属于是 APP,所以可以获取到的设备信息更加丰富一些。

主要涉及的表

用户登录 session 记录表

扩展内容1 - 单点登录 SSO

在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。

定义取自百度百科,之前做外包项目一直就没碰到过这个需求,但大概了解单点登录的概念。

SSO 主要功能

  • 所有应用系统共享一个身份认证系统

统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较,对用户进行登录认证;认证成功后,认证系统应该生成统一的认证标志(ticket),返还给用户。另外,认证系统还应该对 ticket 进行效验,判断其有效性。

  • 所有应用系统能够识别和提取 ticket 信息

要实现 SSO 的功能,让用户只登录一次,就必须让应用系统能够识别已经登录过的用户。应用系统应该能对 ticket 进行识别和提取,通过与认证系统的通讯,能自动判断当前用户是否登录过,从而完成单点登录的功能。

概念比较复杂,实现也比较困难。我的理解,就像是公交卡系统,本来苏州有苏州的公交卡系统,盐城有盐城的公交卡系统,不同城市之间各自为营,不能互通。如果我经常在苏州和盐城来往(没车,只能坐公交 OωO ),一种方法就是我买两张公交卡,一张苏州的,一张盐城的。但这样的话,我就需要同时维持两个公交卡的使用。还有一张方法就是买一张江苏省通用的公交卡(要苏州和盐城的公交卡系统都能够识别),这样就方便了很多,起码钱包里能节省点空间 ヾ(≧∇≦*)ゝ 。公家卡通用要做很多事情,首先这张公家卡要能够提供有效并且安全的认证信息,证明是省内通用的,然后所有支持的城市都要升级公家卡系统,以支持这张公交卡能够被识别。

SSO 当然会对用户提供一些便利,登录信息也能共享。但就跟一句俗语说的一样,不要把所有的鸡蛋都放在一个篮子里,如果认证系统崩溃了,那么所有只支持 SSO 的应用系统都会崩溃。

扩展内容2 - 扫码登录

扫码登录主要用于存在多个客户端的场景。在一些支持 APP 的网站上,使用 APP 扫描网站上的二维码,在 APP 端授权登录,即可让网站跳过输入用户名、密码的相对来说繁琐且不太安全的登录方式,直接登录。

之前做过一个公会的 APP,有一个管理后台,在后台管理系统上,添加了一个扫码登录的登录方式。当时参考了网上的一些方案,选择了最简单的方法实现。

管理后台页面每次切换到扫码登录页面,会在用户表中更新授权登录的随机字符串(其实可以存放在 redis 之类的缓存中),根据随机字符串生成一个登录二维码返回给前端,二维码里面存放的是随机字符串加密后的 hash 值。前端做一个定时器,定时询问后台当前会话是否已授权登录。并且二维码会定时过期,刷新后会重新请求二维码,后端生成新的随机字符串,并生成二维码返回前端,这点比较像验证码的刷新机制。当用户通过 APP 调用扫码并确认授权登录后,会将二维码中获取的加密的 hash 值通过接口传递到后端。后端解密之后取出当前 APP 登录用户的随机字符串与之比对,如果相同则修改用户授权登录状态为允许。当前端定时询问在后端得到允许后,后端为当前会话添加登录状态,并修改授权登录状态为不允许,同时更新随机字符串,等待下一次的请求,前端登录成功。

基本的逻辑是这样的,当然为了安全和用户体验,还有很多可以优化的点。比如说二维码的过期可以放在轮询请求中,一过期,就更新随机字符串,当前端提交刷新请求时,生成二维码返回就行。前端可以获取一些当前需要授权登录设备的信息,比如说 IP 地址和设备类型,将这些信息以 hash 值作为主键存储好,在扫码后先去获取授权登录的设备及 IP 地址信息,并展示在 APP 端提供授权参考依据,之后确认授权登录,再去修改授权登录状态。