向各位请教,RESTful 的登录设计的原理是什么

最近有点钻牛角尖,开始学习用 RESTful 设计服务器接口,又涉及到登录操作,查了好些资料,发现重点是 HTTPS 和 Token 验证
我这里有几个问题没搞明白,请教各位

  1. 有没有 RESTful 登录 可以参考的项目,不要 redis 的
  2. RESTful 登录是否需要配置 https
  3. 后端拿到Token是怎么处理的

话不多说了,我先跪了
image

https://www.purcellyoon.com/insights/articles/symfony-4-using-the-json-login-with-remember-me

  1. https://github.com/search?q=restful+jwt
  2. 正式环境配证书
  3. 解析 token,取出携带的身份信息等

我也不是很清楚,按我 在org-mode内折腾下来 的简单理解,关键在于后端为用户的每一次登陆都生成一个不会重复的id,然后这个id发回前端加密存储,再然后前端每次向后端发起请求时都带有这个加密存储的数据,这样后端就能识别用户是已经登陆的,不用每次都去校验用户名密码

应该不需要https吧,否则在没有公共域名只有公共ip的情况下不太好办

RESTFul 登陆跟传统登陆实际上没区别, 只是为了鉴权采用了Token 这种方式,但是Token的设计千奇百怪,常见的Oauth, JWT等,实际上你用Cookie也没关系的,只是安全上面弱一点,遇到跨域就无法鉴权什么的了。所以才会流行JWT之类的。。

至于https只是安全上面的考虑,对http协议传输进行加密而已。如果是强安全性业务这个是必须加的,一般web服务,不强制性,当然。。。现在都推https保障安全性(避免中间人劫持)。

参考我的Python项目模版

1 个赞

参考JWT流程图,网上找的, 所有的基本登陆认证流程都差不多。

2 个赞

其实就是登录成功之后,服务器交给客户端一个临时身份证,客户端向服务器要什么都需要带上身份证,身份证的含义只有服务器自己知道,服务器可以根据身份证识别你是谁。

传递身份证的时候被人拦截到怎么办,用https吗?

是的。。。。

RESTful 跟 Token 不是必然的关系。你也可以用 Session 来做登录认证。

RESTful 是一种设计范式。可以看看《 理解RESTful架构 - 阮一峰的网络日志 》:

总结一下什么是RESTful架构:

(1)每一个URI代表一种资源;

(2)客户端和服务器之间,传递这种资源的某种表现层;

(3)客户端通过四个HTTP动词,对服务器端资源进行操作,实现"表现层状态转化"。

还有个小问题,多用户登录怎么办

1 个赞

用ID区分是一个好的办法

服务器会保存一个token<->用户的对照表,查表就可以知道是哪个用户了

这个没关系呀,登陆认证回来一个临时token,存下来,继续登陆回来又是一个新的token, 然后你拿着这些token去请求资源基本上都是ok的,就看业务系统有没有才有单IP做防御,做了防御,就可能需要一个IP代理池来解决了。

首先token生成一般是: UID + Scope(用户权限) + 过期时间,三个要素,使用非对称加密等手段生成的一个字符串,也就是token,用户注册后UID是唯一的,用户每次登录,是可以获取到用户的UID,每次会根据UID+Scope+过期时间生成一个token,登录一般就是获取这个token的动作,然后访问其它接口,就需要携带这个token,访问接口携带的token会被接口做解密,解出来token里面包含的UID,Scope,过期时间信息,然后可以对这三个信息做校验,校验能通过就可以访问该接口,校验不过就403

RESTful的核心思想是充分利用HTTP协议本身的机制构建Web服务。所以RESTful的场景最重要的是定义若干资源,然后以不同的HTTP请求方法(GET/POST/UPDATE/PATCH/DELETE)形成远程的数据库风格的CRUD操作。

在用户登录这个情景里,如果用RESTful的方法设计,那么存在两个资源实体:用户(User)和会话(Session)。

用户是什么不需要多说,惟一要注意的是千万别明文存密码,有bcrypt这种成熟方案。

会话表示一个抽象的用户登录状态,它和用户的关系是多对一(也就是一个用户可以有多个登录会话)。根据业务场景的复杂与否,这个会话实体可以没有对应的真实数据库表,也可以有一个专门的session表,这对应着两种情况:

  • 没有session表,表示登录状态没有保存在服务端而是存在客户端,只是用密码学方式(服务端密钥签名)证明这个登录状态的确是服务端签发的。传统的加密Cookie或者JWT(JSON Web Token)就属于这种情况。这种情况的优点是服务端不需要专门存取会话(Token)信息,缺点是服务端无法对登录状态进行撤销(revoke)操作。
  • 有session表,这种情况服务端能做的事情更多,比如某些网站里你可以查看有多少浏览器/客户端登录了本账号,并且撤销登录。在RESTful API的情境里,Token是由服务端随机生成并存入session表和用户ID关联起来。缺点是每次登录服务端都要查表验证Token是否过期是否正确。这个和Redis没任何关系,因为登录Token可以正常存在数据库里,用Redis只是性能优化的考虑。

RESTful和https没有任何关系。只不过2022年了,正常的网站都应该全站HTTPS,否则某些浏览器API都不能用。

2 个赞