在@CL-北京在1电脑修改密码之后,2电脑还可以正常使用该账号,2电脑退出软件重新打开还是可以正常使用
为保证安全,客户端是不存储密码的,存储的是在登录的时候从服务器端返回具有一定有效期的token(凭据)。 为保证离线可用,这个token是一直存储的,直到过期或从客户端退出帐号。 因为token是在服务器端生成并加密的,客户端无法伪造,所以在token合法的情况下,服务器端都认为是帐号正常的操作。 所以会出现你说的那个情况,这是正常的。另外一个帐号会有多个token同时有效,比如在每个不同的电脑上登录,都会生成新的token,此时旧token并不会失效。 这个设计是一个非常常用的设计方式,可以搜索JWT了解。 Quicker设计的场景主要是个人在自己电脑上使用,如果在其他人的电脑上使用,用完之后注意要退出帐号一下。
token有效时间有多久?
是100天,方便在离线环境使用的时候不用经常连线。
你那边具体是什么情况呢? 是在公共电脑上使用没有退出么?
修改密码之后token还有效我觉得这个有一定的安全问题。。
如果处于离线环境token可以正常使用这个还好,但是当处于有网络的情况下,应该添加一个验证token是否有效的判断吧,改密码之后token应该失效才对😂。
如果改密码后,我在此账号创建新的隐私动作,还会同步到旧密码的设备可正常同步使用,这个逻辑我觉得是错误的。。
或者增加一个设备管理,可设置让在某设备的token失效。
嗯,了解你的担心,网络上对这种模型的讨论很多。
对于只在自己电脑上使用的场景是完全没问题的。对于混用电脑有你说的这个情况。
JWT凭据的特点是无状态,这样这样服务器端只要解密验证里面的信息是不是合法就可以了,不需要再访问数据库或其他后台资源进行额外验证,会节约服务器资源,也便于把一些服务分布到不同的服务器和系统中。
鉴于Quicker是一个以帐号为基础的个人软件,综合考虑之后就直接采用这个模型了。
后期如果共享电脑的情况比较多,就再增加一些额外的验证,客户端也可以考虑增加一个不在本地保存数据文件的方式,只要关闭了就重新输入密码。
为保证安全,客户端是不存储密码的,存储的是在登录的时候从服务器端返回具有一定有效期的token(凭据)。
为保证离线可用,这个token是一直存储的,直到过期或从客户端退出帐号。
因为token是在服务器端生成并加密的,客户端无法伪造,所以在token合法的情况下,服务器端都认为是帐号正常的操作。
所以会出现你说的那个情况,这是正常的。另外一个帐号会有多个token同时有效,比如在每个不同的电脑上登录,都会生成新的token,此时旧token并不会失效。
这个设计是一个非常常用的设计方式,可以搜索JWT了解。
Quicker设计的场景主要是个人在自己电脑上使用,如果在其他人的电脑上使用,用完之后注意要退出帐号一下。
token有效时间有多久?
是100天,方便在离线环境使用的时候不用经常连线。
你那边具体是什么情况呢? 是在公共电脑上使用没有退出么?
修改密码之后token还有效我觉得这个有一定的安全问题。。
如果处于离线环境token可以正常使用这个还好,但是当处于有网络的情况下,应该添加一个验证token是否有效的判断吧,改密码之后token应该失效才对😂。
如果改密码后,我在此账号创建新的隐私动作,还会同步到旧密码的设备可正常同步使用,这个逻辑我觉得是错误的。。
或者增加一个设备管理,可设置让在某设备的token失效。
嗯,了解你的担心,网络上对这种模型的讨论很多。
对于只在自己电脑上使用的场景是完全没问题的。对于混用电脑有你说的这个情况。
JWT凭据的特点是无状态,这样这样服务器端只要解密验证里面的信息是不是合法就可以了,不需要再访问数据库或其他后台资源进行额外验证,会节约服务器资源,也便于把一些服务分布到不同的服务器和系统中。
鉴于Quicker是一个以帐号为基础的个人软件,综合考虑之后就直接采用这个模型了。
后期如果共享电脑的情况比较多,就再增加一些额外的验证,客户端也可以考虑增加一个不在本地保存数据文件的方式,只要关闭了就重新输入密码。