小编Cha*_*112的帖子

所以,我正在使用Java验证Facebook的signed_request.不幸的是,我一直在遇到验证过程中的问题.我查看了这个文档,并模拟了他们的算法,但没有成功.我也遵循了本教程,并继续提出我的计算签名与Facebook发送的签名不同.

或者至少,这就是String.equals()告诉我的.

所以我决定再捅一下.

我将其设置为迭代计算签名中的字节和提供的字节.低,看,我的签名的前32个字节完全匹配他们.它只是缺少另外400多字节的数据.

那时,我觉得我应该更好地了解到底发生了什么.我查了一下SHA-256,发现确实只创建了32个字节的信息.那么我留下了超过400字节的数据,Facebook声称是使用HMAC SHA-256算法生成的.我想我应该比较SHA-256的最大长度与我散列数据的长度,但只是表明,有办法,方式,方法有很多剩余空间(邮件大小:575个字节;最大尺寸:2.305843009213694 x 10 ^ 18字节).

Facebook会搞砸吗？或者我错过了什么？

编辑

这是我用来散列数据的函数.我传入我的facebook密码(用于密钥)和base64url编码的JSON对象(用于数据).它始终返回长度为32的字节数组,其数据与facebook提供的签名的前32个字节相匹配.

private byte[] hmacSHA256(String data, String key) throws Exception {
    SecretKeySpec secretKey = new SecretKeySpec(key.getBytes("UTF-8"), "HmacSHA256");
    Mac mac = Mac.getInstance("HmacSHA256");
    mac.init(secretKey);
    mac.update(data.getBytes("UTF-8"));
    byte[] hmacData = mac.doFinal();
    return hmacData;
}

我只花了最后两个小时抨击我的额头对着我的代码,试图弄清楚它有什么问题.我最终把它缩小到一对线.

NSArray *components = [string componentsSeparatedByString:@" "];

if ([components count] > 1){                        
    retainedProperty1 = [header objectAtIndex:0];

    retainedProperty2 = [header objectAtIndex:1];
}

每当我在执行延迟后尝试访问这些字段中的任何一个时(我正在使用CocoaAsyncSocket,并且它会在第二次从套接字读取时引入此对象所需的其余数据),它们都会变为僵尸.我只是想知道为什么会发生这种情况？