如果有多个发送者id，如何确定令牌是否需要刷新？
我的应用程序正在收到来自2 firebase项目的推送通知。我通过分别调用“getToken（String authorizedEntity，String scope）”来获取每个发送者id的令牌。
String token1 = FirebaseInstanceId.getInstance().getToken("authorizedEntity1", "FCM");
String token2 = FirebaseInstanceId.getInstance().getToken("authorizedEntity2", "FCM");
根据onTokenRefresh文档
当系统确定令牌需要刷新时调用。应用程序应该调用getToken（）并将令牌发送到所有应用程序服务器。这不会被频繁调用，关键点旋转和处理实例ID更改需要它，因为：
应用程序删除实例ID
应用程序在新设备上恢复
用户卸载/重新安装应用程序
用户清除应用程序数据
由于onTokenReFresh已被弃用，我已检查onNewToken，根据留档
为默认Firebase项目生成新令牌时调用。这是在应用程序安装后首次生成令牌时调用的，并且在令牌更改时再次调用。
问题1.如果有多个发送者id，如何知道默认的Firebase项目是哪一个？
假设“authorizedEntity1”与默认firebase项目关联，那么这是否意味着只有在令牌1更改时才会调用onNewToken？或者当token2更改时也会调用它？如果它不适用于令牌2，那么如何知道令牌2需要刷新？
考虑到这一点，我的理解是，每当需要刷新任何令牌时，都会调用onTokenRefresh（不仅仅是对于默认项目）。这种理解正确吗？
每当系统确定需要刷新令牌1或令牌2时，我想将更新的令牌发送到服务器。
注意：我正在初始化我的应用程序类中的Firebase，因为我正在处理多个发件人id。
共有2个答案
根据接触Firebase支持的@sNash comment，您应该管理除默认发件人id之外的所有发件人id的令牌。
怎样一个简单的解决方案是将所有发送方ID及其令牌存储在SharedReferences或db中。当应用程序启动时，通过将存储的令牌与
FirebaseInstanceId.getInstance().getToken(SENDER_ID, "FCM");
此外，在NewToken方法上执行相同的检查。更改默认令牌时，可能会更改默认令牌以外的令牌。
默认发件人是与应用程序连接的Firebase项目相关的发件人，可以在google-services.json中找到
经过一些测试，我发现只有默认项目的令牌才会交付给onNewToken。当通过调用getToken为其他发件人ID创建新令牌时，不会调用onNewToken。
通过调用getToken API检索的令牌由与默认令牌不同的字符串数据组成。
当默认令牌更改时，这些其他发送者id的令牌不会刷新。看起来它们会一直持续到显式调用deleteToken API为止。（当我反复调用getToken时，令牌值没有改变。）
-
我已经阅读了跑道文档。我特别考虑了以下关于使用的声明： 此请求返回与上述相同的数据，您可以继续反复执行此操作，以保持应用程序的身份验证，而无需要求用户重新身份验证。 这是否意味着将无限期有效或过期： < li >签发后X天；或者 < li >最后一次使用它获取新的< code>access_token后的X天 编辑：请参阅此跑道线程，该线程提出相同的问题，但似乎没有给出任何关于Oauth2.0协议
-
问题内容： 在我的应用程序中，当用户成功登录时，我将返回访问令牌和刷新令牌。访问和刷新令牌的到期时间已分别设置为10分钟和40分钟。（我应该对这些值进行更多研究。这只是为了测试） 我使用了以下文章中描述的实现 http://www.svlada.com/jwt-token-authentication-with-spring- boot/ 假设我在登录10分钟后向服务器调用了一个请求。由于访问令牌
-
我的应用程序使用Google refresh令牌（从Google获得access_token)。我在这里有两个问题： 我知道谷歌刷新令牌不会在6个月内过期（见这里的文档）；假设我在1月1日下午5:00pm获得了一个刷新令牌，并且我的应用程序在1月1日下午5:30从Google请求了另一个刷新令牌，那么旧的刷新令牌是否仍然有效（显然旧的还没有过期）？--基本上，我询问新发出的refresh_toke
-
问题内容： 因此，我对PHP文件有了一个基本的.ajax（）POST方法。 我需要什么安全措施？ 周围有几篇文章提到使用隐藏的MD5输入字段，您可以通过AJAX发送该字段并在PHP文件中进行验证。这足够好吗？ 问题答案： CSRF的风险在于，外部站点可能会将数据发送到您的站点，而用户浏览器会自动将身份验证cookie与它一起发送。 您需要某种方式来执行接收操作（您的方法正在向其发送POST数据），
-
在我最近的遭遇中，我试图实现在前端安全存储的JWT令牌。我以前的方法是在易受XSS攻击的sessionStorage中存储以及。现在，当过期时，我将调用endpoint来获取新的 之后，我们更改实现以防止XSS和CSRF。接下来，Local存储与Cookie 建议将访问令牌存储在内存中，并将刷新令牌存储在cookie中。所以从FE，我们无法访问cookie。（HTTPOnly cookie）和 现
-
我最近一直在搜索刷新令牌和旋转访问令牌，我突然想到了一些东西。 为什么不使用一个令牌而不是访问令牌和刷新令牌？在该令牌有效载荷（声明）中包含一个验证日期，并将验证期设置得很低（就像访问令牌一样），将到期日期设置得很高（就像刷新令牌一样）。 如果验证日期超过服务器上的日期但未过期，服务器将颁发新令牌并使旧令牌无效（通过任何方式，例如令牌黑名单等，就像 AT 过期和使用刷新令牌颁发新令牌一样），如果令