Hi,
i had alot of problems with this Bitcoin API too, specialy the callback URL
after 2 nights of Headaches,i finaly found the problem :p
this is a DEMO, who is interesting to integrate this LOVELY API on his website he can "Check before Buy" here is the link : http://ex-currency.com/btc/index.php
Payment Sent/Recieved/Confirmed IMMEDIATLY
the price of curiosity is 1 USD
Topic: Blockchain Callback URL, Stripping Characters? (Read 2313 times)
Correct - it should only be at the end of the "key"
What I'm actually finding now is that blockchain.info will 'decode' the URL on their side after an address is successfully created... So once they get a deposit to a particular address, they are invoking the callback URL without the encoded values, so if a '+" or "=" is in the URL, it will get hairy on my side.
For example, if I send over the following key to blockchain.info
?key=xyz123%2B456abc
It will come to my server as "?key=xyz123+456abc" and my application will treat this as two strings " "xyz123" and "456abc" as the internet protocol will substitute the + for a space as it gets to my server.
What I'm actually finding now is that blockchain.info will 'decode' the URL on their side after an address is successfully created... So once they get a deposit to a particular address, they are invoking the callback URL without the encoded values, so if a '+" or "=" is in the URL, it will get hairy on my side.
For example, if I send over the following key to blockchain.info
?key=xyz123%2B456abc
It will come to my server as "?key=xyz123+456abc" and my application will treat this as two strings " "xyz123" and "456abc" as the internet protocol will substitute the + for a space as it gets to my server.
Thanks for the clarification on blockchain.info and the help!
I will give that a whirl, I believe you are correct that it will work in the event there are 0,1,2 "=" at the end of the string. My only concern now is that there won't be "=" embedded in the string (not the end) that get stripped out.
I will give that a whirl, I believe you are correct that it will work in the event there are 0,1,2 "=" at the end of the string. My only concern now is that there won't be "=" embedded in the string (not the end) that get stripped out.
The "=" symbols are not part of the base64 encoding, other than identifying padding at the end of the string. The only two non-letter characters are "+" (%2B) and "/" (%2F). Since there are %2F sequences and "+",%2B signs in the string in both places, it looks like you are okay. The equals signs appear to be the only thing missing.
Thanks for the clarification on blockchain.info and the help!
I will give that a whirl, I believe you are correct that it will work in the event there are 0,1,2 "=" at the end of the string. My only concern now is that there won't be "=" embedded in the string (not the end) that get stripped out.
I will give that a whirl, I believe you are correct that it will work in the event there are 0,1,2 "=" at the end of the string. My only concern now is that there won't be "=" embedded in the string (not the end) that get stripped out.
Two things:
(1) When referring to blockchain.info please use .info. "The blockchain" is the heart of the decentralized bitcoin network, and is completely different than blockchain.info which is a centralized service that helps people like you access data in the blockchain.
(2) The string you've highlighted in red is Base64 used to pass data in a URL. Any two-character sequences preceded by a "%" is an "escape" character that otherwise would muck up your URL. In this case, %3D is actually an equals-sign "=". It's usually the end of the base64 string that explains how much padding to use. Anywhere you see the %3D is simply a way to pass equals signs in a URL without actually confusing any other URL interpreters that otherwise use equals signs for other things.
If those characters are being stripped, you might just have to try it with 0, 1 or 2 equals signs, and then decode the base64. I believe there is only ever 0, 1 or 2, depending on how many bytes of padding are on the end of the string. If you use the wrong number, you either error out (unlikely) or just get the wrong answer (more likely). But one of them will work.
(1) When referring to blockchain.info please use .info. "The blockchain" is the heart of the decentralized bitcoin network, and is completely different than blockchain.info which is a centralized service that helps people like you access data in the blockchain.
(2) The string you've highlighted in red is Base64 used to pass data in a URL. Any two-character sequences preceded by a "%" is an "escape" character that otherwise would muck up your URL. In this case, %3D is actually an equals-sign "=". It's usually the end of the base64 string that explains how much padding to use. Anywhere you see the %3D is simply a way to pass equals signs in a URL without actually confusing any other URL interpreters that otherwise use equals signs for other things.
If those characters are being stripped, you might just have to try it with 0, 1 or 2 equals signs, and then decode the base64. I believe there is only ever 0, 1 or 2, depending on how many bytes of padding are on the end of the string. If you use the wrong number, you either error out (unlikely) or just get the wrong answer (more likely). But one of them will work.
*** Feel free to Move this Mods, I believe it's in the wrong place -- Sorry! ***
Hey Folks -
We are currently undergoing a new technique for our callback transactions, and we seem to be finding a potential bug with Blockchain and how they post callback URLs using their API. We haven't gotten very far with their general support, so we are hoping someone here can articulate what we are doing wrong or get the attention of the right guys at Blockchain to respond to our threads.
Without getting into specifics, we generate a unique callback key for each user that registers on our site by encrypting a series of data tied to that user. Before generating a call to Blockchain, we also urlencode() the secret key as it contains specials characters that won't play well in the browser. Below would be an example call to Blockchain
https://blockchain.info/api/receive?method=create&address=&shared=false&callback=/callback.php?key=Qy5Z5sCNkYCoCmv2ppn1nw4qU3UsrS4TA%2Fx0nPQOsNBaTMAjl6HceHOBQsCeiKal2w0NEXbvJKF9x%2BIvTrgfoA%3D%3D
Once we get the response from hitting the URL above, everything looks great - they replay the callback URL exactly as we put it in, and we get a unique receiving address as well.
So far, so good - now is when things get weird.
Once we send BTC to the new bitcoin receiving address returned above, the following full callback URL is triggered from Blockchain.
/callback.php?anonymous=false&shared=false&destination_address=&confirmations=0&address=&value=600000&input_address=&input_transaction_hash=&key=Qy5Z5sCNkYCoCmv2ppn1nw4qU3UsrS4TA%2Fx0nPQOsNBaTMAjl6HceHOBQsCeiKal2w0NEXbvJKF9x+IvTrgfoA&transaction_hash=e1fd6dadc0...&
You'll notice the 'key' parameter is actually stripped of the last two "%3D"'s rending our decryption routine obsolete?
Now - If someone can tell me why this is happening, I will gladly fork over a donation! I'm really hoping it's somewhere on our side, but after looking at this all weekend, I don't think it is.
Hey Folks -
We are currently undergoing a new technique for our callback transactions, and we seem to be finding a potential bug with Blockchain and how they post callback URLs using their API. We haven't gotten very far with their general support, so we are hoping someone here can articulate what we are doing wrong or get the attention of the right guys at Blockchain to respond to our threads.
Without getting into specifics, we generate a unique callback key for each user that registers on our site by encrypting a series of data tied to that user. Before generating a call to Blockchain, we also urlencode() the secret key as it contains specials characters that won't play well in the browser. Below would be an example call to Blockchain
https://blockchain.info/api/receive?method=create&address=
Once we get the response from hitting the URL above, everything looks great - they replay the callback URL exactly as we put it in, and we get a unique receiving address as well.
So far, so good - now is when things get weird.
Once we send BTC to the new bitcoin receiving address returned above, the following full callback URL is triggered from Blockchain.
You'll notice the 'key' parameter is actually stripped of the last two "%3D"'s rending our decryption routine obsolete?
Now - If someone can tell me why this is happening, I will gladly fork over a donation! I'm really hoping it's somewhere on our side, but after looking at this all weekend, I don't think it is.
Jump to: