为什么服务端不能一直保存用户的登录信息

Question

我们是前端跟安卓和ios混合开发的app，服务端为什么不能一直保存用户登录信息？比如用户开始登录了我们app，然后不管是发帖，收藏，回复，点赞等，都要向安卓ios客户端取得用户的登录信息再发给服务端，服务端再判断用户此时是否登录！用户登录的时候已经取得了登录信息发送给服务端了。比如，key,time,name等信息，可是为什么后面用户其他所有操作，都要再发一次？

Answer 1

服务端是一直保存登录信息，但是服务端需要根据客户端发过来的信息来判断该用户是否登录过的，只要是能标识用户登录信息的都可以。比如 sessionid

Answer 2

两种开发方式都可以，这需要看整个项目的具体设计。
假设采取用户数据存储在后端的方案，那么前端也需要有对应的标识来告诉服务器当前这个请求是哪个用户的，就类似于Map数据结构中的key，也就意味着无论是哪一种方式，前端的每个请求都应该带有直接或者间接标识用户信息的数据。
所以实际上选取哪一种方式不是最重要的，最重要的是如何保证这个直接或间接标识用户信息的数据的安全性和可靠性。

Answer 3

设计的有问题，登陆的时候 应该在服务器上存了一份token 类似 http的session 其他请求自动带上这个信息，不用传用户信息到服务器

Answer 4

问这个问题说明基础没有理解到，http请求是无状态的，同一个客户端的多次请求和其他客户端的请求对服务器来说都是调用接口，都是一样的。而这时服务端要判断哪个请求是哪个用户操作的就需要在你发请求的时候告诉服务器，所以你每次发请求的时候都要带上一定信息cookie或者token

Answer 5

我感觉你们的流程是这样的：

1. 用户通过原生的界面登录app，然后app保存用户状态，然后在app内打开html级别的页面进行发帖等一系列操作，html页面这时候并没有用户信息啥的。

2. 这个时候登录信息或者什么东西是存在原生跟服务器通信之间的。然而发帖等并不需要通过app那一层，所以拿不到用户信息？所以每次都需要从原生处拿一遍，主动发给服务器(而不是通过cookie自然的带过去)？

3. 你现在疑问的是为什么每次都需要js去原生拿一次用户信息交给服务器判断状态，而不是第一次拿过之后后面就不需要了？

看起来是服务器并没有对html级别的接口存session？是这样的吗？
如果是这样的话感觉后端接口有点问题啊。就算对应客户端和内嵌html是两套接口也不至于每次都要html这部分主动发送用户信息啊(可能这部分接口只是单纯的数据接口？)。

---

我们当时是这么做的：当时没想好用户权限原生跟html怎么处理，所以一切用户操作都给了原生，html就展示了静态数据。也可能是我们的功能比较简单，所以这样处理适用。

Answer 6

WebView嵌套的Html，后端存的session是会丢失的。。。这样的话就要后端生吃token，前端每个请求自带token，注意token的时效性、安全性（验签）。