0

我正在构建一个将朋友数据导入本地数据库的应用程序，它运行良好。

我正在尝试创建一个由每日 cron 运行的脚本，该脚本将遍历本地数据库中的用户配置文件并更新朋友数据。

我正在使用 PHP SDK。

我已启用 depreacte_offline_access 标志。

这是否意味着访问令牌将在 60 天后自动过期，还是我需要做其他事情？

如果用户在同一个浏览器中退出应用程序或 Facebook，我还能从 cron 脚本中检索配置文件数据吗？

我是否正确地认为我需要做的就是通过以下方式检索访问令牌：

$access_token = $facebook->getAccessToken();

然后将其存储在数据库中，然后使用以下命令设置访问令牌：

$facebook->setAccessToken($new_access_token);

然后用

$facebook->getUser('/me');

?

另外如何查看访问令牌的到期日期？

下面是一个遍历和检索配置文件的脚本，但如果我在浏览器中运行它，它只适用于当前登录的用户，或者我得到异常“OAuthException：验证访问令牌时出错：会话无效，因为用户已注销。 "

<?php
require_once(THEME_INCLUDES_PATH . 'facebook.php');

$config = array();
$config['appId'] = APP_ID;
$config['secret'] = APP_SECRET;
$config['fileUpload'] = false; // optional

$facebook = new Facebook($config);

$sql = "SELECT `access_token` FROM `fb_user`";
$result = $db1->db_query($sql);

while($details = $db1->db_fetch_array($result)){

    if($details['access_token']){

        $facebook->setAccessToken($details['access_token']);
        $fb_user = $facebook->getUser('/me');

        if($fb_user){

            try {
                $fb_profile = $facebook->api('/me');        
                print_r( $fb_profile);
            }

            catch (FacebookApiException $e){
                echo $e;
                $fb_user = false;
            }
        }
    }
}
?>
4

1 回答 1

0

You have no way of doing what you want now that the offline_access got deprecated.

The idea is that your app only has access to the user data when the user actually interacts with your application. The access token is valid for about 60 days (depending on how you get it), but it can get invalidated due to all kind of reasons (such as user removes your app, changes password, and many more).

When that happens, or the expiration dates arrives, there's nothing that you can do in order to get a new token, unless of course the user reengages your app and then you can get a new token or extend the one you have.

You'll have to make all of the data updating when the user actually interacts with your app and not later on.

In the official post about the deprecation of the offline_access it says:

The user must access your application before you're able to get a valid "authorization code" to be able to make the server-side OAuth call again. Apps will not be able to setup a background/cron job that tries to automatically extend the expiration time, because the "authorization code" is short-lived and will have expired.

Edit

The official post: Removal of offline_access Permission describes a new endpoint to extend valid access tokens, in one of two cases: If the app got the token from a client-side flow or with a signed request:

Using the new endpoint below, you will be able to extend the expiration time of an existing, valid access_token. If the access_token was originally generated from a client-side OAuth call or through a signed_request, the endpoint will actually return a new access_token.

It also states that:

If the access_token is generated from a server-side OAuth call, the resulting access_token will have the longer expiration time.

So my advise is simple to use the server-side flow to generate the access token.

As for a list of token invalidating events, they don't have a complete list, but you can find info about it in the same page:

Handling expired tokens, user password changes, uninstalled apps, and user logout

Regardless if your app requested the offline_access permission, apps should gracefully handle an expired access tokens in situations where a user changes their password, deauthorizes an app, or logs out. More information on these cases including a simple code solution that leads to a uniform user experience can be found in this blog post.

And you can check this doc: Handling Invalid and Expired Access Tokens.

于 2012-04-13T14:41:30.127 回答