问题表现:
刚使用postman请求/easportal/openapi/login获取到token,再用token去请求业务接口,就让重新登陆。
问题原因:
携带appid的登陆请求,返回的token经过后端json数据化之后一些符号被转化Unicode编码,如果把token直接复制到另外的请求中使用就会有问题,原则上必须先对Unicode编码的数据进行解码。(请注意如果是在后端java代码中使用EASLoginContext的模式来调用openApi则不会存在上述问题,这些问题的场景仅限于直接拿到token,且登陆请求需要携带appid)
下面看被Unicode编码后的数据是啥样子的(取自上面的截图例子):
JSRGQDWtwghtsMBHLiF2e/G79C2S5zcYbM/DNAlo+tQ9wtdYfA7IksXgehom6GR4yypJhLO8uE8B\\nWtleYH7tGQ\\u003d\\u003d
可以看到这个数据后面由两个重复的\\u003d,其实\u003d对应的是 = (等于号),多的 \ 是转义字符。通过在线Unicode解码网站(https://c.runoob.com/front-end/3602/),解码之后是:
JSRGQDWtwghtsMBHLiF2e/G79C2S5zcYbM/DNAlo+tQ9wtdYfA7IksXgehom6GR4yypJhLO8uE8B\\nWtleYH7tGQ\=\=
最终在把=号和\n之前的\去掉,下面的token就可以在postman中使用了
JSRGQDWtwghtsMBHLiF2e/G79C2S5zcYbM/DNAlo+tQ9wtdYfA7IksXgehom6GR4yypJhLO8uE8B\nWtleYH7tGQ==
补充:如果上述处理完之后依然让重新登录,则查看下token中是否有特殊符号 比如说加号(+),有的话则需要对token做下编码,比如说在浏览器中使用:encodeURIComponent:
推荐阅读