Hi everyone!
Thanks Chris for your answer it help me going further.
So, under linux I try to access to my IG account with curl:
/oliver> curl -k -v -H "Content-Type: application/json; charset=UTF-8" -H "Accept: application/json; charset=UTF-8" -H "X-IG-API-KEY: XXXXXXXXXXXXXXXXXXXXXXXXXXXX" -H "version: 1" -u mrpa665:XXXXXXX -X POST https://api.ig.com/gateway/deal/session
but I received a HTTP/1.1 400 Bad Request message:
* About to connect() to api.ig.com port 443
* Trying 23.76.156.136... connected
* Connected to api.ig.com (23.76.156.136) port 443
* successfully set certificate verify locations:
* CAfile: /usr/share/curl/curl-ca-bundle.crt
CApath: none
* SSLv2, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using AES256-SHA
* Server certificate:
* subject: /serialNumber=04008980/1.3.6.1.4.1.311.60.2.1.3=GB/1.3.6.1.4.1.311.60.2.1.2=London/2.5.4.15=Private Organization/C=GB/postalCode=EC4R 2YA/ST=London/L=London/streetAddress=Cannon Bridge House, 25 Dowgate Hill/O=IG Group Limited/OU=IT Production/OU=Comodo EV SAN SSL/CN=www.ig.com
* start date: 2014-09-08 00:00:00 GMT
* expire date: 2015-08-06 23:59:59 GMT
* subjectAltName: api.ig.com matched
* issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Extended Validation Secure Server CA 2
* SSL certificate verify result: error number 1 (20), continuing anyway.
* Server auth using Basic with user 'mrpa665'
> POST /gateway/deal/session HTTP/1.1
> Authorization: Basic bXJwYTY2NTpvTGkzLDdYcg==
> User-Agent: curl/7.15.1 (ia64-suse-linux) libcurl/7.15.1 OpenSSL/0.9.8a zlib/1.2.8 libidn/0.6.0
> Host: api.ig.com
> Content-Type: application/json; charset=UTF-8
> Accept: application/json; charset=UTF-8
> X-IG-API-KEY: ebfdec284d7a218f7bfb816a2586a34bb79873fa
> version: 1
>
< HTTP/1.1 400 Bad Request
< Server: Apache
< Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS
< Pragma: no-cache
< Cache-Control: no-cache, no-store
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Content-Language: en-GB
< P3P: CP="ALL DSP LAW OTPa OUR IND UNI CNT"
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: Content-Type, X-IG-API-KEY, CST, X-SECURITY-TOKEN, VERSION, _method
< Access-Control-Expose-Headers: CST, X-SECURITY-TOKEN
< Content-Type: application/json;charset=UTF-8
< Vary: X-IG-API-KEY
< Date: Wed, 07 Jan 2015 10:50:02 GMT
< Connection: close
SSLv3, TLS alert, Client hello (1):
Closing connection #0
* SSLv3, TLS alert, Client hello (1):
{"errorCode":"invalid.input"}
What i do wrong?
Thanks a lot,
Olivier
The *body* of your login request should include:
{"identifier":"XXXXX","password":"XXXXX"}
I don't think the "-u" option to curl does the same thing.
Hi APItrader!
I'm not an expert of curl but it seems that IG recognize my user:
extract of the output above:
* SSL certificate verify result: error number 1 (20), continuing anyway.
* Server auth using Basic with user 'mrpa665'
> POST /gateway/deal/session HTTP/1.1
and the curl man page:
-u/--user
Specify user and password to use for server authentication. Overrides -n/--netrc and --netrc-optional.
If you use an SSPI-enabled curl binary and do NTLM autentication, you can force curl to pick up the user
name and password from your environment by simply specifying a single colon with this option: "-u :".
If this option is used several times, the last one will be used.
There is other way to give user and passwd, I will try it
Olivier
* Server auth using Basic with user 'mrpa665'
is a client message, it doesn't mean that the server has accepted it...
I succeeded to made some commands, but ONLY with GET.
For instance:
curl -k -v -H "Content-Type: application/json; charset=UTF-8" -H "Accept: applicaet=UTF-8" -H "X-IG-API-KEY: ********************" -H "version: 1" -H "X-SECURITY-TOKEN: 9d98ee3888b63982a4cb7e5285ebf1af31c48106d742d2083acf6ef2d9e34f7701111" -H "CST: 85fe76a8c7bc4ea4ace04420bb64cca4d2421c64a26bf1d66bf260123c9f8be301113" -X GET https://api.ig.com/gateway/deal/positions
give me a correct answer: < Connection: keep-alive
{"positions":[{"position":{"contractSize":1.0,"createdDate":"2015/01/08 13:57:16:000","dealId":"DIAAAAAX8L3EQAJ","dealSize":5.0,"direction":"BUY","limitLevel":4264.0,"openLevel":4204.8,"currency":"EUR","controlledRisk":false,"stopLevel":4160.0,"trailingStep":null,"trailingStopDistance":null},"market":{"instrumentName": .....
BUT commands with POST or PUT it's NOT working. I have search in the net and it's seems related to access protected HTTPS sites ... for instance see: http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ss... but in that exemple they are using CURL in php and in my case i'm working under linux ...
So problem still not solved
Can you give an example (including header and body of your request) of a POST or PUT that is not working?
I made an upgrade of curl, so the certicate problem is solved in a clean way but the other problem persist
Command:
curl -v -H "Content-Type: application/json; charset=UTF-8" -H "Accept: application/json; charset=UTF-8" -H "X-IG-API-KEY: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" -H "version: 1" -H "X-SECURITY-TOKEN: 944b60ffca4fe6959771c53d78cbaf6a5b618350a0d18106b2f8ba13017dfb4b01111" -H "CST: e51ce05b601d647dd796bedae413e5b7ab4ca2c43335396dbe634e312722abc201113" -X PUT https://api.ig.com/gateway/deal/accounts/preferences -d "trailingStopsEnabled=null"
Answer:
* About to connect() to api.ig.com port 443 (#0)
* Trying 23.76.156.136... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
* subject: serialNumber=04008980; 1.3.6.1.4.1.311.60.2.1.3=GB; 1.3.6.1.4.1.311.60.2.1.2=London; 2.5.4.15=Private Organization; C=GB; postalCode=EC4R 2YA; ST=London; L=London; streetAddress=Cannon Bridge House, 25 Dowgate Hill; O=IG Group Limited; OU=IT Production; O
* start date: 2014-09-08 00:00:00 GMT
* expire date: 2015-08-06 23:59:59 GMT
* subjectAltName: api.ig.com matched
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO Extended Validation Secure Server CA 2
* SSL certificate verify ok.
> PUT /gateway/deal/accounts/preferences HTTP/1.1
> User-Agent: curl/7.23.0 (ia64-unknown-linux-gnu) libcurl/7.23.0 OpenSSL/0.9.8a zlib/1.2.3
> Host: api.ig.com
> Content-Type: application/json; charset=UTF-8
> Accept: application/json; charset=UTF-8
> X-IG-API-KEY: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> version: 1
> X-SECURITY-TOKEN: 944b60ffca4fe6959771c53d78cbaf6a5b618350a0d18106b2f8ba13017dfb4b01111
> CST: e51ce05b601d647dd796bedae413e5b7ab4ca2c43335396dbe634e312722abc201113
> Content-Length: 25
>
* upload completely sent off: 25 out of 25 bytes
< HTTP/1.1 400 Bad Request
< Server: Apache
< Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS
< Pragma: no-cache
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Cache-Control: no-cache
< Cache-Control: no-store
< Pragma: no-cache
< Cache-Control: no-cache, no-store, max-age=0
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Content-Language: en-GB
< P3P: CP="ALL DSP LAW OTPa OUR IND UNI CNT"
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: Content-Type, X-IG-API-KEY, CST, X-SECURITY-TOKEN, VERSION, _method
< Access-Control-Expose-Headers: CST, X-SECURITY-TOKEN
< Content-Type: application/json;charset=UTF-8
< Vary: X-IG-API-KEY
< Date: Fri, 09 Jan 2015 09:13:00 GMT
< Connection: close
<
* SSLv3, TLS alert, Client hello (1):
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
{"errorCode":"invalid.input"}
It seems indeed clearly a problem of sending data ...
We need to use JSON format to encode data:
command:
curl -H "Content-Type: application/json; charset=UTF-8" -H "Accept: application/json; charset=UTF-8" -H "X-IG-API-KEY: XXXXXXXXXXXXXX" -H "version: 1" -H "X-SECURITY-TOKEN: 944b60ffca4fe6959771c53d78cbaf6a5b618350a0d18106b2f8ba13017dfb4b01111" -H "CST: e51ce05b601d647dd796bedae413e5b7ab4ca2c43335396dbe634e312722abc201113" -X PUT https://api.ig.com/gateway/deal/accounts/preferences -d '{ "trailingStopsEnabled": null }'
give the correct answer: {"status":"SUCCESS"}