最近有点钻牛角尖，开始学习用 RESTful 设计服务器接口，又涉及到登录操作，查了好些资料，发现重点是 HTTPS 和 Token 验证
我这里有几个问题没搞明白，请教各位
- 有没有 RESTful 登录 可以参考的项目，不要 redis 的
- RESTful 登录是否需要配置 https
- 后端拿到Token是怎么处理的
话不多说了，我先跪了
我也不是很清楚，按我 在org-mode内折腾下来 的简单理解，关键在于后端为用户的每一次登陆都生成一个不会重复的id，然后这个id发回前端加密存储，再然后前端每次向后端发起请求时都带有这个加密存储的数据，这样后端就能识别用户是已经登陆的，不用每次都去校验用户名密码
应该不需要https吧，否则在没有公共域名只有公共ip的情况下不太好办
RESTFul 登陆跟传统登陆实际上没区别， 只是为了鉴权采用了Token 这种方式，但是Token的设计千奇百怪，常见的Oauth， JWT等，实际上你用Cookie也没关系的，只是安全上面弱一点，遇到跨域就无法鉴权什么的了。所以才会流行JWT之类的。。
至于https只是安全上面的考虑，对http协议传输进行加密而已。如果是强安全性业务这个是必须加的，一般web服务，不强制性，当然。。。现在都推https保障安全性（避免中间人劫持）。
参考我的Python项目模版
1 个赞
其实就是登录成功之后，服务器交给客户端一个临时身份证，客户端向服务器要什么都需要带上身份证，身份证的含义只有服务器自己知道，服务器可以根据身份证识别你是谁。
传递身份证的时候被人拦截到怎么办，用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 个赞