我正在尝试使用php sdk这样获取Facebook用户ID
$fb = new Facebook\Facebook([
'app_id' => '11111111111',
'app_secret' => '1111222211111112222',
'default_graph_version' => 'v2.4',
]);
$helper = $fb->getRedirectLoginHelper();
$permissions = ['public_profile','email']; // Optional permissions
$loginUrl = $helper->getLoginUrl('http://MyWebSite', $permissions);
echo '<a href="' . $loginUrl . '">Log in with Facebook!</a>';
try {
$accessToken = $helper->getAccessToken();
var_dump($accessToken);
} catch (Facebook\Exceptions\FacebookResponseException $e) {
// When Graph returns an error
echo 'Graph returned an error: ' . $e->getMessage();
exit;
} catch (Facebook\Exceptions\FacebookSDKException $e) {
// When validation fails or other local issues
echo 'Facebook SDK returned an error: ' . $e->getMessage();
exit;
}
if (!isset($accessToken)) {
if ($helper->getError()) {
header('HTTP/1.0 401 Unauthorized');
echo "Error: " . $helper->getError() . "\n";
echo "Error Code: " . $helper->getErrorCode() . "\n";
echo "Error Reason: " . $helper->getErrorReason() . "\n";
echo "Error Description: " . $helper->getErrorDescription() . "\n";
} else {
header('HTTP/1.0 400 Bad Request');
echo 'Bad request';
}
exit;
}
// Logged in
echo '<h3>Access Token</h3>';
var_dump($accessToken->getValue());
// The OAuth 2.0 client handler helps us manage access tokens
$oAuth2Client = $fb->getOAuth2Client();
// Get the access token metadata from /debug_token
$tokenMetadata = $oAuth2Client->debugToken($accessToken);
echo '<h3>Metadata</h3>';
var_dump($tokenMetadata);
// Validation (these will throw FacebookSDKException's when they fail)
$tokenMetadata->validateAppId($config['11111111111']);
// If you know the user ID this access token belongs to, you can validate it here
//$tokenMetadata->validateUserId('123');
$tokenMetadata->validateExpiration();
if (!$accessToken->isLongLived()) {
// Exchanges a short-lived access token for a long-lived one
try {
$accessToken = $oAuth2Client->getLongLivedAccessToken($accessToken);
} catch (Facebook\Exceptions\FacebookSDKException $e) {
echo "<p>Error getting long-lived access token: " . $helper->getMessage() . "</p>\n\n";
exit;
}
echo '<h3>Long-lived</h3>';
var_dump($accessToken->getValue());
}
$_SESSION['fb_access_token'] = (string)$accessToken;
但是它给了我这个错误:
Facebook SDK returned an error:
Cross-site request forgery validation failed.
The "state" param from the URL and session do not match.
请任何帮助,我是php的新手,也感谢Facebook sdk的任何帮助。
我发现,只要在生成登录URL之前启用了PHP会话,并且Facebook最终重定向到脚本的顶部,它就可以在不设置cookie的情况下正常运行。这是使用SDK的5.1版本。
在这两个脚本的顶部,我添加了…
if(!session_id()) {
session_start();
}
…而且“行之有效”。
这是一个对我有用的准系统完整示例:
auth.php
if (!session_id()) {
session_start();
}
$oFB = new Facebook\Facebook([
'app_id' => FACEBOOK_APP_ID,
'app_secret' => FACEBOOK_APP_SECRET
]);
$oHelper = self::$oFB->getRedirectLoginHelper();
$sURL = $oHelper->getLoginUrl(FACEBOOK_AUTH_CALLBACK, FACEBOOK_PERMISSIONS);
// Redirect or show link to user.
auth_callback.php
if (!session_id()) {
session_start();
}
$oFB = new Facebook\Facebook([
'app_id' => FACEBOOK_APP_ID,
'app_secret' => FACEBOOK_APP_SECRET
]);
$oHelper = self::$oFB->getRedirectLoginHelper();
$oAccessToken = $oHelper->getAccessToken();
if ($oAccessToken !== null) {
$oResponse = self::$oFB->get('/me?fields=id,name,email', $oAccessToken);
print_r($oResponse->getGraphUser());
}
另外,在回购文档中对此进行了说明。
警告:FacebookRedirectLoginHelper使用会话来存储CSRF值。在调用getLoginUrl()方法之前,需要确保已启用会话。通常,这在大多数Web框架中都是自动完成的,但是如果您不使用Web框架,则可以添加session_start();。到您的login.php和login-
callback.php脚本的顶部。您可以覆盖默认的会话处理-请参阅下面的扩展点。
我要添加此注释,因为如果您碰巧正在运行自己的会话管理或并行运行多个Web服务器,请牢记这一点很重要。在这种情况下,依靠php的默认会话方法将永远无法工作。
CSRF攻击迫使经过身份验证的用户(受害者)发送伪造的HTTP请求,包括受害者的会话cookie到易受攻击的Web应用程序,这允许攻击者强制受害者的浏览器生成请求,以便易受攻击的应用程序感知来自受害者。 我们下面来了解这个漏洞的威胁代理,攻击向量,安全弱点,技术影响和业务影响。 威胁代理 - 任何人都可以将内容加载到用户的浏览器中,从而迫使他们向您的网站提交请求。 攻击者的方法 - 攻击者创建伪造
跨站请求伪造(CSRF)是一种漏洞利用,攻击者致使受害的最终用户按恶意URI(例如以误导的链接、图片或重定向提供给用户代理)到达受信任的服务器(通常由存在有效的会话Cookie而建立)。 针对客户端的重定向URI的CSRF攻击允许攻击者注入自己的授权码或访问令牌,这将导致在客户端中使用与攻击者的受保护资源关联的访问令牌而非受害者的(例如,保存受害者的银行账户信息到攻击者控制的受保护资源)。 客户端
跨站请求伪造(Cross-site request forgery), 简称为 XSRF,是 Web 应用中常见的一个安全问题。前面的链接也详细讲述了 XSRF 攻击的实现方式。 当前防范 XSRF 的一种通用的方法,是对每一个用户都记录一个无法预知的 cookie 数据,然后要求所有提交的请求(POST/PUT/DELETE)中都必须带有这个 cookie 数据。如果此数据不匹配 ,那么这个请求
2.5. 跨站请求伪造 跨站请求伪造(CSRF)是一种允许攻击者通过受害者发送任意HTTP请求的一类攻击方法。此处所指的受害者是一个不知情的同谋,所有的伪造请求都由他发起,而不是攻击者。这样,很你就很难确定哪些请求是属于跨站请求伪造攻击。事实上,如果没有对跨站请求伪造攻击进行特意防范的话,你的应用很有可能是有漏洞的。 请看下面一个简单的应用,它允许用户购买钢笔或铅笔。界面上包含下面的表单: COD
描述 跨站请求伪造,或 CSRF 攻击,在恶意网站、电子邮件、即使消息、应用以及其它,使用户的 Web 浏览器执行其它站点上的一些操作,并且用户已经授权或登录了该站点时发生。这通常会在用户不知道操作已经执行的情况下发生。 CSRF 攻击的影响取决于收到操作的站点。这里是一个例子: Bob 登录了它的银行账户,执行了一些操作,但是没有登出。 Bob 检查了它的邮箱,并点击了一个陌生站点的链接。 陌生
CSRF 中间件和模板标签提供对跨站请求伪造简单易用的防护。某些恶意网站上包含链接、表单按钮或者JavaScript ,它们会利用登录过的用户在浏览器中的认证信息试图在你的网站上完成某些操作,这就是跨站攻击。还有另外一种相关的攻击叫做“登录CSRF”,攻击站点触发用户浏览器用其它人的认证信息登录到其它站点。 防护CSRF 攻击的第一道防线是保证GET 请求(以及在9.1.1 Safe Method