페이 스북 크레딧 콜백, order_id가 새 서버로 이동 한 후 형식 변경 변경

방금 리눅스 기반의 새 서버로 마이그레이션했습니다. 이동 한 후 동작이 변경된 것을 보았습니다. 어떤 이유에서 주문 ID가 페이스 북 크레딧 콜백을 통해 2.6040261734251E + 14 다음과 같은 형식으로 페이로드로 전송됩니다. 143121239125639 (이들은 반드시 동일한 주문 번호 일 필요는 없습니다. 형식을 참조하십시오 ...페이 스북 크레딧 콜백, order_id가 새 서버로 이동 한 후 형식 변경 변경

$ _REQUEST에서 가져온 직후 및 DB 삽입 전에 형식이 도착합니다 ... 누구나 그 형식이 변경/도착하는 이유는 무엇입니까? 감사합니다.

--- 편집 --- 나는 parse_signed_request 기능을 사용하여 서명 요청에서 변수를 받고 있어요 : 찰리 P., 난 정말 대신 32 비트 서버를 사용하고 발견으로

function parse_signed_request($signed_request, $secret) { 
    list($encoded_sig, $payload) = explode('.', $signed_request, 2); 

    // decode the data 
    $sig = base64_url_decode($encoded_sig); 
    $data = json_decode(base64_url_decode($payload), true); 

    if (strtoupper($data['algorithm']) !== 'HMAC-SHA256') { 
    error_log('Unknown algorithm. Expected HMAC-SHA256'); 
    mail('[email protected]','server error','Unknown algorithm. Expected HMAC-SHA256'); 
    return null; 
    } 

    // check signature 
    $expected_sig = hash_hmac('sha256', $payload, $secret, $raw = true); 
    if ($sig !== $expected_sig) { 
    error_log('Bad Signed JSON signature!'); 
    return null; 
    } 

    return $data; 
}

64 비트 이전 서버. 다시

json_decode(base64_url_decode($payload), true);

감사를 사용하는 이상 그것은 어떻게 든

출처

2011-11-22 Yanipan

마지막에 'E + 14'는 14 개의 후행 0이 있다는 것을 의미합니다 ... oddd –

참으로 기가 바이트 ... 실제로 DB에 입력되면 실제로는 거의 확인되지만 마지막 숫자는 0으로 바뀝니다. 하나 ... – Yanipan

귀하의 이전 서버가 64 비트되어 있어야합니다 ... 기능을 파괴하고 새 서버가

문자열로 원래의 번호를 사용하려고 32 비트

입니다 수

출처

2011-11-22 06:56:05

답변 주셔서 감사합니다 ... 나는 값에 대한 숫자 조작, 난 그냥 진실 된 페이 스북 parse_signed_request 함수를 전달 서명 된 요청에서 그것을 해독 할 때 ... 어떤 생각을 어쩌면 내가 막 다른 골목에있어 ... – Yanipan

@ Yanipan 그래서 문제가 귀하의 데이터베이스에있는 마지막 번호입니까? 숫자를 테이블에 삽입하는 데 사용하는 코드의 예를 제공 할 수 있습니까? –

페이 스북 크레딧 콜백, order_id가 새 서버로 이동 한 후 형식 변경 변경

답변

관련 문제