我啥时候需要使用存储在数据库中的访问令牌?

Posted

技术标签:

【中文标题】我啥时候需要使用存储在数据库中的访问令牌?【英文标题】:When do I need to use the access token stored in the database?我什么时候需要使用存储在数据库中的访问令牌? 【发布时间】:2012-07-14 18:56:42 【问题描述】:

何时需要使用存储在数据库中的访问令牌?

此访问令牌是用户访问令牌。 似乎 php SDK 在自己获取访问令牌方面做得很好。虽然这看起来像是通过 Session 处理的。 -- 如果 Session 以某种方式被擦除怎么办? -- 我应该提供一个链接吗? -- 或者我应该/可以以某种方式自动执行此操作吗? 我是 Facebook 开放图形 API 的新手。 我正在使用 Facebook PHP SDK。

我也对 Facebook 上的文档和实现 PHP SDK 感到有些困惑。在花了相当多的时间混合和调整两者之后,我意识到文档中的几乎所有示例都是 PHP SDK 的一部分。因此我的上述问题。

【问题讨论】:

根本不需要存储access_token。很有可能,下次您想使用它时,它已经过期了。当然,除非您使用的是扩展的 access_token... 我今天早些时候刚刚回答了这个关于 Twitter api 问题的问题,所以也许这会有所帮助:-***.com/questions/11491674/… Lix 是对的(应该是一个答案)。 我正在使用扩展访问令牌。我的应用使用了 60 天的长期令牌。 【参考方案1】:

没有真正的理由需要在数据库中存储用户 access_token。下次你来使用它的机会是 - 它已经无效了。根据我的经验,它们只持续一两个小时。官方文档指出:

当您从 Facebook 获取访问令牌时,它将是有效的 在一段时间内立即并可用于对 API 的请求 由 Facebook 定义。这段时间过去后,访问令牌 被认为已经过期,用户需要 再次进行身份验证,以便您的应用获得新的访问权限 令牌。给定访问令牌的有效期取决于 它是如何生成的。

没有关于(正常)令牌有效多长时间的具体时间段,因此没有理由存储它。如果您希望使用 API 获得所有交易的详尽日志,您可以将令牌存储为参考 - 但 IMO 太过分了...

存储令牌的唯一原因是您正在处理扩展的 access_tokens。如果您正在研究该领域,我可以推荐这篇文章- “http://facebook.***.com/questions/8982025/how-to-extend-access-token-validity-since-offline-access-deprecation”。它似乎是处理扩展 access_token 有效性的最全面的帖子。如果您想在用户不一定连接到您的应用程序时代表用户调用 Graph API(或为此根本登录 Facebook),您将需要这样做 - 不要知道我是否喜欢这样...

【讨论】:

我正在使用扩展访问令牌。我的问题不在于延长 2 小时短暂的令牌,我已经看到了像您在需要时发布的那样的解决方案。我在这里和其他地方看过很多帖子,建议应该将访问令牌存储在数据库之类的某个地方。但由于 PHP SDK 做了这么多工作,我开始质疑是否需要存储它,或者至少何时使用它。我相信如果我要发布到粉丝页面,我将不得不更改 PHP SDK 正在使用的访问令牌。 好的,那么如果会话由于某种原因被擦除了怎么办?因为这似乎为我保留了访问令牌,直到它过期,如果 PHP SDK 似乎会为我请求一个新的。 我想这是与原帖不同的问题。

以上是关于我啥时候需要使用存储在数据库中的访问令牌?的主要内容,如果未能解决你的问题,请参考以下文章

Firebase:我啥时候应该使用 refreshToken?

我啥时候应该使用一对一的关系?

我啥时候应该在 Symfony 4.4 控制器中使用拒绝访问功能?

我啥时候应该使用准备好的语句?

我啥时候应该考虑使用内存数据库,需要注意啥问题?

我啥时候应该使用 PHP 会话、浏览器本地存储和 JavaScript 对象参数?