Tweet
A few months ago I downloaded and began using the BASE64_H and BASE64R4 programs from Scott Klements site along with downloading and modifying some programs I found on Mysample code for HASH & HMAC.
All is going very well with using them - but occasionally - approximately 1 in 175 transactions one of my SHA1-HMAC Base64 encoded signatures come out "wrong". It seems is always the last 3 positions of the signature that is the problem and the "incorrect" value is always ending in == where on the ones I have checked using another base64 program the results end with 2 different characters and a single =.
If that is not fishy sounding enough - I get a "bad signature" error back for the web site I am sending it to - I rerun and it's fine. The only thing involved in the calculation that would be different the 2nd time through is the timestamp.
Because my failures are happening in the middle of the night in the middle of a batching type situation I thought there might be some overlay of data going on so I spent a bunch of time examining today and had someone process the same information I am processing in the RPG programs in a PHP program they wrote. We picked a transaction that had failed for me last night and used the log data to reprocess. We checked the data every step of the way and found the data matches up until I execute the Base64 encode. In this case my vendor and my co-worker receive back LQ2N8eqdkQFweWrWIR2terNr0kA= my program calculates LQ2N8eqdkQFweWrWIR2terNr0g==
If we rerun using the timestamp from when I reran the process we both get the same result.
//API to calculate the SHA1 hash
Qc3CalculateHMAC( Datatohash
: datalen
: 'DATA0100'
: alg
: 'ALGD0500'
: my_key
: 'KEYD0200'
: '0'
: *omit
: HMACOutput
: ErrorNull );
cvthc( $hex: HMACOutput: %len(HMACOutput)*2);
Output = *blanks; <----------------------------------at this point comparing hex values we match
base64_encode( %addr(HMACOutput)
: %len(%trimr(HMACOutput))
: %addr(Output)
: %size(Output) );
<---------------------------------But output doesn't match here.
I am mystified.
Ideas? Thoughts? Suggestions?
Marianne
All is going very well with using them - but occasionally - approximately 1 in 175 transactions one of my SHA1-HMAC Base64 encoded signatures come out "wrong". It seems is always the last 3 positions of the signature that is the problem and the "incorrect" value is always ending in == where on the ones I have checked using another base64 program the results end with 2 different characters and a single =.
If that is not fishy sounding enough - I get a "bad signature" error back for the web site I am sending it to - I rerun and it's fine. The only thing involved in the calculation that would be different the 2nd time through is the timestamp.
Because my failures are happening in the middle of the night in the middle of a batching type situation I thought there might be some overlay of data going on so I spent a bunch of time examining today and had someone process the same information I am processing in the RPG programs in a PHP program they wrote. We picked a transaction that had failed for me last night and used the log data to reprocess. We checked the data every step of the way and found the data matches up until I execute the Base64 encode. In this case my vendor and my co-worker receive back LQ2N8eqdkQFweWrWIR2terNr0kA= my program calculates LQ2N8eqdkQFweWrWIR2terNr0g==
If we rerun using the timestamp from when I reran the process we both get the same result.
//API to calculate the SHA1 hash
Qc3CalculateHMAC( Datatohash
: datalen
: 'DATA0100'
: alg
: 'ALGD0500'
: my_key
: 'KEYD0200'
: '0'
: *omit
: HMACOutput
: ErrorNull );
cvthc( $hex: HMACOutput: %len(HMACOutput)*2);
Output = *blanks; <----------------------------------at this point comparing hex values we match
base64_encode( %addr(HMACOutput)
: %len(%trimr(HMACOutput))
: %addr(Output)
: %size(Output) );
<---------------------------------But output doesn't match here.
I am mystified.
Ideas? Thoughts? Suggestions?
Marianne
Comment