织梦网站做关键词,滕州做网站比较好的网络公司,网址怎么申请,赣州建设网原文链接#xff1a;https://kixuan.github.io/posts/f568/ 对jwt总是一知半解#xff0c;而且项目打算写个关于JWT登录的点#xff0c;所以总结关于JWT的知识及网上面试考察过的点 参考资料#xff1a; Cookie、Session、Token、JWT_通俗地讲就是验证当前用户的身份,证明-… 原文链接https://kixuan.github.io/posts/f568/ 对jwt总是一知半解而且项目打算写个关于JWT登录的点所以总结关于JWT的知识及网上面试考察过的点 参考资料 Cookie、Session、Token、JWT_通俗地讲就是验证当前用户的身份,证明-CSDN博客 JSON Web Token 入门教程 - 阮一峰的网络日志 https://cloud.tencent.com/developer/article/2231547 JWT详细讲解(保姆级教程)-阿里云开发者社区 JWT双令牌(双token)实现登录验证_双token三验证-CSDN博客 零、前置知识
cookie、session、token的区别
cookie用于在客户端存储会话信息并在之后每个请求中都会通过HTTP头部再将cookie发给服务器 》对于敏感信息不安全跨站脚本、跨站请求伪造
session是基于 cookie 实现的session 存储在服务器端sessionId 会被存储到客户端的cookie 中然后请求服务器的时候只发送Sessionid》用户量特别大时服务器容易分配。
token可以存储在客户端或者服务器端具体取决于实现方式。常见的做法是将 Token 存储在客户端比如在 localStorage、sessionStorage 或者浏览器的内存中。///无状态///可拓展性强可以包含任何信息
Cookie 和 Session 的区别
安全性 Session 比 Cookie 安全Session 是存储在服务器端的Cookie 是存储在客户端的。存取值的类型不同Cookie 只支持存字符串数据想要设置其他类型的数据需要将其转换成字符串Session 可以存任意数据类型。有效期不同 Cookie 可设置为长时间保持比如我们经常使用的默认登录功能Session 一般失效时间较短客户端关闭默认情况下或者 Session 超时都会失效。存储大小不同 单个 Cookie 保存的数据不能超过 4KSession 可存储数据远高于 Cookie但是当访问量过多会占用过多的服务器资源。
为什么session比cookie安全
可被篡改性Cookie 存储在客户端可以在客户端被修改。相比之下Session 数据通常存储在服务器端攻击者无法直接修改。
可被窃取性同上
持久性这意味着即使用户关闭浏览器这些 Cookie 也会被保存在用户的设备上。长时间的持久性可能增加了攻击者窃取 Cookie 的机会
Token 和 Session 的区别
Session 是一种记录服务器和客户端会话状态的机制使服务端有状态化可以记录会话信息。而 Token 是访问资源接口API时所需要的资源凭证使服务端无状态化不会存储会话信息。
一、出现背景
在传统的 Web 开发中为了保持用户的会话状态通常会使用基于 cookie 和 session 的方式保存相关数据如用户角色、登陆时间。但也有一些问题比如跨域资源共享CORS和无状态Stateless服务。
如果是服务器集群或者需要CORS的架构要求session数据库共享
解决办法
session数据持久化——写到数据库或者别的持久层工程量较大稳定性不高持久层挂了就会单点失败服务器不保存session数据数据保存在客户端每次请求带上发回给服务器
JSON Web Token缩写 JWT是2方案的一个代表是目前最流行的跨域认证解决方案
基于session的认证流程基于JWT的认证流程用户在浏览器中输入用户名和密码服务器通过密码校验后生成一个session并保存到数据库服务器为用户生成一个sessionId并将具有sesssionId的cookie放置在用户浏览器中同时 Cookie 记录此 SessionID 属于哪个域名在后续的该域名的请求中都将带有这个cookie信息进行访问服务器获取cookie通过获取cookie中的sessionId查找数据库判断当前请求是否有效用户在浏览器中输入用户名和密码服务器通过密码校验后生成一个token并保存到数据库前端获取到token存储到cookie或者local storage中在后续的请求中都将带有这个token信息进行访问服务器获取token值通过查找数据库判断当前token是否有效
二、原理
组成部分
JWT 的原理基于三部分组成Header、Payload 和 Signature。它们通过点.连接在一起形成一个紧凑的字符串可以通过 URL、POST 参数或 HTTP 头部发送。
Header包含了两部分信息令牌的类型即JWT以及所使用的签名算法例如HMAC SHA256或RSA。Payload存放着声明claims即关于实体通常是用户和其他数据的信息。Payload包含了一些预定义的标准声明如issuer、subject、audience等同时也可以包含自定义的声明。Signature用于验证消息的完整性的签名部分。它由将编码的 header、payload 和一个秘密例如使用 HMAC 算法时的密钥进行签名生成。 运行流程
Header部分是一个 JSON 对象描述 JWT 的元数据,使用 Base64URL 算法转成字符串
{alg: HS256, // 签名算法typ: JWT // 令牌类型
}Payload:服务器认证以后生成一个 JSON 对象用来存放实际需要传递的数据再使用 Base64URL 算法转成字符串
// JWT 规定了7个官方字段供选用也可以定义私有字段
- iss (issuer)签发人
- exp (expiration time)过期时间
- sub (subject)主题
- aud (audience)受众
- nbf (Not Before)生效时间
- iat (Issued At)签发时间
- jti (JWT ID)编号{姓名: 张三,角色: 管理员,到期时间: 2018年7月1日0点0分
}Signature:通过将 Base64 编码后的 Header 和 Payload 与一个秘密例如使用 HMAC 算法时的密钥进行签名生成的。 指定一个密钥密钥只有服务器知道然后使用 Header 里面指定的签名算法alg算出签名客户端收到服务器返回的 JWT可以储存在 Cookie 里面也可以储存在 localStorage。此后客户端每次与服务器通信都要带上这个 JWT(也可以放在HTTP请求头信息里的Authorization字段,方便跨域)
三、代码实现
参考JWT双令牌(双token)实现登录验证_双token三验证-CSDN博客
双令牌无感登录刷新 access_token 泄露概率比较大 refresh_token 泄露概率比较小,只有每次access_token 失效时才会使用它,所以二者组合可以很好的避免token泄露带来的安全风险,同时又能保证用户体验 userService的login方法 保存refresh token到数据库access token返回给前端 刷新accessToken当短时间的token过期前端需要通过长时间的token来访问后端并且生成一个短时间的token返回给前端也就是刷新短时间的token。 删除refreshToken当用户退出的时候我们需要删除数据库中的refreshToken。
四、相关面试题来源牛客
1. jwt的token怎么生成的?/jwt的参数是什么样的有什么意义
由三个部分组成Header、Payload 和 Signature。其中Header 和 Payload 部分是基于 Base64 编码的 JSON 对象而 Signature 是通过对 Header 和 Payload 进行签名生成的。
再说运行流程
2. jwt 是明文的吗
Header 和 Payload 是基于 BaseURL64 编码的 JSON 对象明文存放的
Signature 是加密的但是它主要适用于验证JWT的真实性防止被篡改不存放信息
所以整体来说JWT还是明文的
3. JWT用到了什么摘要算法
摘要算法摘要算法又称哈希算法、散列算法。它通过一个函数把任意长度的数据转换为一个长度固定的数据串通常用16进制的字符串表示。
要注意摘要算法不是加密算法不能用于加密因为无法通过摘要反推明文只能用于防篡改。
SHA256是一种哈希算法用于将任意长度的输入数据转换成固定长度的输出256 位即 32 字节
工作原理
填充数据首先SHA256 将输入数据填充至满足特定要求的长度通常在数据末尾添加比特位以确保数据长度满足要求。分块处理将填充后的数据按照固定长度分割成多个块每个块的长度为 512 比特。初始哈希值设定初始的 256 比特哈希值作为计算的起始点。迭代运算对每个块进行迭代运算结合前一个块的哈希值计算得到新的哈希值直到处理完所有块。输出结果将最后一个块计算得到的哈希值作为最终的 SHA256 哈希值输出。
特点
固定长度输出SHA256 输出固定长度的哈希值即使输入数据的长度不同输出的哈希值长度仍然相同。不可逆性SHA256 是一种单向哈希函数即无法通过哈希值反推出原始数据保证了数据的安全性。抗碰撞性SHA256 具有较高的抗碰撞性即使对不同的输入数据计算得到相同的哈希值的可能性极低保证了数据的唯一性和完整性。
4. 可以使用md5摘要算法吗
MD5 摘要算法不建议用于 JWT 的签名因为 MD5 已经被证明不安全容易受到碰撞攻击。碰撞攻击是指攻击者能够生成两个不同的输入但产生相同的哈希值。
为什么选sha256不选md5
摘要长度SHA256 生成的摘要长度256 比特比 MD5 长度128 比特更长因此具有更大的输出空间更难以发生碰撞即两个不同的消息产生相同的摘要。算法结构SHA256 是基于 Merkle–Damgard 结构的散列函数而 MD5 是基于 MD4 结构的。SHA256 的算法结构更为复杂使用了更多的轮次和更复杂的运算提高了其抵抗碰撞攻击的能力。算法安全性MD5 算法在安全性上存在一些漏洞如碰撞攻击、预图片攻击等已经被证明不再安全。而 SHA256 目前尚未出现有效的攻击方法因此被认为更安全。
5. 了解RAS算法吗
rsa是一种非对称加密算法数据可以使用公钥进行加密然后只有持有相应私钥的一方才能解密该数据。反之数据也可以使用私钥进行签名然后任何持有相应公钥的一方都可以验证该签名。
在JWT的应用私钥用于生成签名而公钥用于验证签名。这样即使公钥泄露攻击者也无法伪造有效的签名从而确保了 JWT 的安全性。 我趣那不是又能深入可以到对称加密和非对称加密 对称加密相同密钥、快速高效 非对称加密不同密钥、安全性较高 6. base64算法base64的流程是什么
Base64 编码算法Base64 算法将二进制数据编码成文本字符串但并不对数据进行加密或者隐藏。它的主要目的是将二进制数据转换成纯文本格式以便于传输或者存储。【24位转32位】
把数据按照24位3 字节为一组进行划分转成ASCII编码——转成二进制编码24位——每6位一组转成十进制4个数字——转成对应的ASCII编码——转成二进制32位如果输入数据的长度不是 3 的整数倍则需要添加一定数量的填充字符 “”使得每个 24 位的组都能够被正确地转换成四个 Base64 字符。
参考https://blog.csdn.net/qq_19782019/article/details/88117150
7. 双令牌认证方案是怎么实现的
同时使用访问令牌Access Token和刷新令牌Refresh Token来实现用户认证和无感登录刷新。这种方案可以有效地提高安全性和用户体验具体实现方式如下
认证过程 用户使用用户名和密码等凭据进行登录服务器验证用户身份并生成 Access Token 和 Refresh Token。Access Token 用于访问受保护的资源通常具有较短的有效期比如几分钟到几小时。Refresh Token 用于获取新的 Access Token通常具有较长的有效期比如几天到几个月。 Access Token 过期处理当 Access Token 过期时用户需要使用 Refresh Token 来获取新的 Access Token而无需重新输入用户名和密码。Refresh Token 安全性 Refresh Token 通常具有较长的有效期因此需要确保其安全性防止被盗用。可以通过以下方式提高其安全性 将 Refresh Token 存储在安全的地方比如 HTTP-only Cookie 或者安全存储。使用 HTTPS 加密传输 Refresh Token防止被中间人窃取。 Access Token 的定期刷新在获取新的 Access Token 时可以同时返回新的 Refresh Token以确保用户持续的访问权限。
通过双令牌认证方案用户可以在不影响用户体验的情况下持续访问受保护的资源并且可以有效地提高安全性防止令牌被截取或滥用。
8 .为什么需要JWT/解决了什么问题相比之前的 cookie session 改用 jwt 有什么好处
JWT 和cookie session功能类似都是用于身份验证和授权
优点
无状态服务器不需要再内存中保存用户的会话信息因为JWT中已经包含了用户的所有必要信息跨域支持因为JWT是在网络请求的头部中传输的而cookiesession跨域访问需要额外的配置和处理可扩展性强可以包含任意的Json数据满足不同场景的需求性能更好减少服务器负载还可以通过缓存或者CDN进行缓存进一步提升性能安全性数字签名和加密算法
9. 整个JWT是怎么设计的
令牌类型JWTJSON Web Token令牌内容确定令牌中包含的信息如用户身份信息、权限信息、过期时间等。令牌签名或加密使用后SHA256进行签名令牌传输 HTTPS 加密通信令牌存储本地存储如 Local Storage 或者 Session Storage、HTTP Only Cookie 中令牌刷新机制双令牌认证方案令牌管理好像没有
Or 见代码实现part
10. 令牌存储/为什么用redis存jwt
本地Local Storage
服务器Redis
提高性能、减轻数据库负担、高可用性、分布式系统、数据持久化
11. 怎么防止别人用你的token干坏事
分两步防止别人拿到token防止别人干坏事
防止别人拿到token
使用安全的传输协议比如使用 HTTPS 协议来加密通信防止中间人窃取 token。限制 token 的使用有效期刷新 token 机制使用签名验证在验证 token 时确保 token 的签名是有效的并且是由信任的签发者签发的。这可以防止伪造 token 或者篡改 token 内容。
防止别人干坏事
限制 token 的使用范围限制 token 只能用于特定的 API 路径或者特定的操作定期监控 token 的使用情况
12. 使用JWT时如果一个用户把token给了另外一个用户恶意同时登录怎么处理 ?
限制令牌的使用范围可以在 JWT 中包含一些额外的声明Claims如用户的 IP 地址、用户角色等信息实施单点登录SSO限制用户同时登录的设备数量限制有效期定期监控
13. 对比jwt与token
格式JWT 是一种特定的令牌格式它使用 JSON 对象作为载荷并使用签名或加密来保证其完整性和安全性。而 Token 则是一个更广义的概念可以是任何形式的凭证。安全性JWT 通过签名或加密来保证其安全性而普通的 Token 可能没有这种安全保障。使用场景JWT 主要用于实现无状态的身份验证和授权而 Token 可以用于各种场景包括 OAuth 授权、访问令牌、刷新令牌等。
总的来说JWT 是 Token 的一种特定格式它具有一定的安全性和标准化适用于实现无状态的身份验证和授权。而 Token 则是一个更广义的概念可以是各种形式的凭证用于各种身份验证和授权场景。
14. cookie了解吗
存储在客户端的小型文本文件用于跟踪用户在网站上的活动并且在用户访问同一网站时发送回服务器。
它们经常被用来实现用户认证、会话跟踪、个性化设置等功能。
由一组名称/值对组成以及一些可选的属性。 属性name——表示名称 expires——过期时间 path——可以访问路径 domain——可访问域名 secure—— 只能通过 HTTPS 连接传输 HttpOnly——只能通过 HTTP 或 HTTPS 协议访问而不能通过客户端脚本如 JavaScript访问以防止跨站脚本XSS攻击。 使用cookie需要注意安全性跨站脚本XSS攻击和跨站请求伪造CSRF
15. 再让你优化项目还能怎么优化
减小 JWT 的大小只包含必要的信息缓存用户信息减少每次请求都需要解析 JWT 的开销。实现 Token 的刷新机制减少用户频繁登录的次数提高用户体验。限制 Token 的访问权限可以减少对数据库的访问次数提高性能。使用 CDN 和反向代理可以使用 CDN内容分发网络和反向代理来缓存和分发 JWT Token减轻服务器的负载提高响应速度。
16. 如何防止jwt传输途中被截取
使用 HTTPS 加密传输最有效的方式是通过使用 HTTPS 协议来加密通信。HTTPS 使用了 TLS/SSL 加密技术避免在 URL 中传输 JWT不要将 JWT 直接作为 URL 参数传递因为 URL 参数可能会被记录在日志中或者在浏览器历史记录中留下痕迹增加了被截取的风险。而是应该将 JWT 放在 HTTP 头部的 Authorization 字段中进行传输。实现 Token 的签名验证在服务器端对接收到的 JWT 进行签名验证确保 JWT 的完整性。使用短期有效的 JWT实现 Token 的刷新机制额外的安全层在 JWT 中添加额外的安全层如 CSRF Token防止 CSRF 攻击或者在敏感操作中使用双因素身份验证等。
17. JWT缺点
无法撤销一旦 JWT 被签发除非它达到了过期时间否则它就是有效的。体积较大JWT 包含了一些额外的信息如标头、声明和签名等无法进行会话管理无法像传统的基于会话的身份验证那样进行会话管理如主动注销或者强制用户重新验证。安全性依赖于密钥安全性不适用于敏感信息存储
18. JWT能够保证安全性吗
Or 保证token存储在本地安全
JWT 本身并不能完全保证安全性它只是一种规范和标准用于生成和传递令牌。安全性取决于如何使用 JWT 以及其他安全措施的配合。如
使用安全的存储机制选择适合的存储机制来存储 Token如浏览器的本地存储如 Local Storage 或者 Session Storage、HTTP Only Cookie 等服务端管理好密钥定期更新令牌限制令牌访问范围HTTPS加密传输避免在url中传递敏感信息避免XSS跨站脚本攻击
19. 如何保证token过期刷新
使用刷新令牌除了访问令牌Access Token外还可以为用户颁发一个刷新令牌Refresh Token
在访问令牌过期之前每次访问可以通过向服务器发送特定的请求来刷新令牌
20. 无状态登录和有状态登录的区别
无状态登录Stateless Login 在无状态登录中服务器不需要保存用户的会话状态。客户端在之后的每次请求中都会将该 JWT 作为身份凭证发送给服务器服务器只需要验证 JWT 的有效性而不需要在服务器端保存任何会话信息。由于服务器不保存会话状态因此无状态登录适用于分布式和跨域应用环境具有更好的可扩展性和性能。 有状态登录Stateful Login 在有状态登录中服务器需要在服务器端保存用户的会话状态。每次用户进行身份验证时服务器会将用户的会话信息保存在服务器端并返回一个会话标识符Session ID给客户端。客户端在之后的每次请求中都会将会话标识符发送给服务器服务器通过会话标识符来识别用户的会话状态从而进行身份验证和授权。
21. 退出登录、注册怎么通过JWT实现
退出登录退出登录通常意味着销毁客户端保存的 JWT 令牌。 客户端发送一个特殊的请求如注销请求到服务器端。服务器端收到注销请求后将相应用户的 JWT 令牌加入一个黑名单列表或者删除相应的令牌信息。客户端收到服务器的响应后删除本地存储的 JWT 令牌使用户被注销。 注册 客户端向服务器发送注册请求包含新用户的注册信息如用户名和密码等。服务器接收到注册请求后验证注册信息的合法性并创建新用户。随后服务器生成相应用户的 JWT 令牌并将其返回给客户端。客户端收到服务器返回的 JWT 令牌后将其保存在本地以便在以后的请求中使用。
22. 如果用户更改了密码如何处理jwt令牌
让令牌失效
强制用户重新登录当用户更改密码后服务器端直接删除用户之前的所有 JWT 令牌并要求用户重新登录。使用密码加盐在用户更改密码时修改用户的密码同时也修改密码的盐值。添加版本号或时间戳在 JWT 的负载中添加一个版本号或者时间戳字段表示用户的密码版本或者密码修改时间。
23. 怎么让JWT提前失效
设置过期时间expJWT 的playLoad中包含了一个名为 “exp” 的声明可以设置撤销令牌维护一个令牌撤销列表当用户注销或者改变了密码时将相应的令牌加入到撤销列表中以使这些令牌失效。使用刷新令牌刷新令牌有更长的有效期可以获取访问令牌。一旦刷新令牌失效或者被使用之前颁发的访问令牌就会提前失效。
24. 强行让JWT失效会发生什么事情
JWT通常被设计为服务器不需要在数据库中存储任何关于令牌的信息
然而如果强行让 JWT 失效通常需要在服务器端维护一个令牌的黑名单或者撤销列表这就涉及到在数据库或者其他持久化存储中存储令牌信息违背了 JWT 无状态的初衷。
25. 除了JWT还有没有别的方案它们之间的优缺点分别是什么
Cookie sessionOAuth通常用于实现第三方登录JWT实现无状态的用户身份验证和授权适用于需要在不同的应用之间传递用户身份信息的情况如单点登录、跨域认证等。
26. 介绍一下单点登录jwt怎么实现单点登录
单点登录Single Sign-On简称 SSO是一种身份认证的机制允许用户通过一次登录就能够访问多个相关的系统或服务。
在一个认证中心进行登录获取JWT然后访问其他服务都将这个JWT作为身份凭证发送给服务端
而且JWT可以实现自定义声明适用于单点登录
27. 跨域是什么为什么会有跨域问题
跨域Cross-Origin是指在 Web 开发中当一个域名下的文档或脚本试图去请求另一个域名下的资源时就会产生跨域问题。
跨域流程
用户登录用户在任意一个服务器上进行登录登录成功后服务器生成 JWT 并将其返回给客户端。JWT 传递客户端收到 JWT 后将其保存在本地通常是在浏览器的本地存储如 Local Storage或者 Cookie 中。跨域请求用户在其他服务器上进行访问时客户端将 JWT 放入请求头中通常是 Authorization 头发送到另一个服务器。JWT 验证另一个服务器接收到请求后验证 JWT 的签名和有效期。如果验证通过则说明用户已经通过认证可以继续处理请求否则返回相应的错误信息。响应处理另一个服务器处理完请求后可以生成新的 JWT 并返回给客户端以便客户端在下次请求时继续使用。
跨域问题产生的原因主要有以下几点
同源策略Same-Origin Policy同源策略是浏览器的一项安全策略限制了一个域下的文档或脚本与另一个域下的资源进行交互。同源策略规定了只有当请求的协议、主机和端口号完全一致时才允许进行跨域请求否则就会产生跨域问题。安全性考虑跨域请求可能会带来安全隐患比如跨站脚本XSS攻击和跨站请求伪造CSRF攻击等。浏览器为了保护用户的信息安全因此默认情况下会阻止跨域请求。浏览器限制浏览器出于安全考虑对跨域请求进行了限制包括不允许跨域读取 Cookie、不允许跨域访问 DOM 和不允许跨域发送 AJAX 请求等。
跨域问题会影响到 Web 开发中的很多场景比如跨域 AJAX 请求、跨域资源共享CORS、跨文档消息传递PostMessage等。为了解决跨域问题通常可以采取以下几种方法
CORSCross-Origin Resource Sharing通过服务端设置响应头来允许跨域请求从而在客户端浏览器上解决跨域问题。 使用 CrossOrigin 注解全局配置 CORSpublic class CorsConfig implements WebMvcConfigurer通过配置文件配置 CORS WebSocketWebSocket 不受同源策略的限制可以通过建立 WebSocket 连接来实现跨域通信。
28. 企业有多个服务器多个域名怎么实现jwt除了jwt还有哪些能实现跨域认证
单点登录JWT包含域名信息使用统一的认证服务器负责用户身份认证和生成 JWT。所有的服务器都向该认证服务器发送认证请求验证用户身份后生成 JWT 返回给客户端。
其他跨域认证方法
1.OAuth2.0
29. 场景题设计一个手机端扫码登录电脑端的的功能
生成登录二维码 在电脑端的登录页面上生成一个登录二维码。二维码内容可以是一个唯一的标识符代表着当前登录会话的标识。 手机端扫码验证二维码 手机端扫描到二维码后将二维码的内容发送到服务器进行验证。服务器验证二维码的有效性并确定该二维码对应的登录会话是否有效。 登录确认 如果二维码有效服务器返回登录确认信息给手机端。手机端接收到确认信息后提示用户确认登录操作。 登录处理 用户在手机端确认登录操作后手机端发送登录请求给服务器携带用户身份信息。服务器验证用户身份信息并在后台完成登录流程。 登录状态同步 服务器在登录成功后在电脑端和手机端均生成对应的登录状态信息如登录令牌或者会话标识。电脑端和手机端均保存登录状态信息以便在后续的操作中进行身份验证和授权。 登录完成 登录完成后电脑端和手机端均显示登录成功的提示。用户可以在电脑端和手机端自由操作并保持登录状态的同步。
30. 其他websock…
如何自定义登录接口以及jwt过滤器
websocket 轮询什么的
扩展集成 Sa-token 实现角色认证和权限认证并使用Redis集成进行缓存添加API签名参数增强
Sa-Token
oauth2.0 vs ssojwt 双token
为什么不选择SpringSecurity 、Shiro
需求能否被胜任单点登录, 身份切换, 等等等等, 以及可能产生的需求, auth2, 动态鉴权上手难度小SaToken最简单, Shiro中规中矩, SpringSecurity最繁琐友好程度文档是否友好, demo是否完善, 以及各大论坛博客文章错误内容多不多. 如果是中文的话SaToken更友好, 英文则SpringSecurity
登录的逻辑需要从请求发到服务端开始说清楚springmvc的处理流程然后在到业务处理包括方法的返回值都要说清楚。
API签名参数
