Api V2 And Encrypted Shares

[Moe]

Hey!

 

I can't find out how to set a folder as encrypted. I can get a status of a share if it supports it but I could not find a boolean that says someting like "encrypt: true".

 

Any tips?

[Moe]

Ok. New week, new luck.

 

Anyone any idea how you set that up in API v2?

[Corin]

Based on my reading of the v2 docs, I'd say you're out of luck.  They seem to be read-only settings.

[Moe]

Based on my reading of the v2 docs, I'd say you're out of luck.  They seem to be read-only settings.

 

Yeah I am also that far but I know that they refer to the old secret system - there you can create a secret that tells the BTS executable that this share is encrypted. But how do you set this with the new API.

Is it not supported yet? Is it on their todo list? Is it something they don't want to support? And if yes, why? Because I know plenty of very good reasons for encrypted shares.

 

Basically now I am waiting for someone of the BTS Team to give some feedback on this.

 

/e

 

Ok I found this: http://forum.bittorrent.com/topic/40814-how-to-create-sync-folders-not-classic-using-v2-api/

Let's see and wait.

 

BUT I still want to have it confirmed by someone if possible

[RomanZ]

@Moe

 

You have to add a new folder using encrypted secret. Try calling

/api/v2/secret

with POST method and send

{"type":1}

as message body. Sync will create a set of Encrypted secrets for you. Now add a new folder using

/api/v2/folders

POST method and pass the secret you get as a parameter.

[Moe]

Ok so I tried the following

curl -u admin:password -X POST -H "Content-Type: application/json" -d '{"type":1}' http://localhost:8888/api/v2/secret

And it gave me this

pi@raspberrypi:~$ curl -u admin:password -X POST -H "Content-Type: application/json" -d '{"type":1}' http://localhost:8888/api/v2/secretinvalid requestpi@raspberrypi:~$

What am I missing? :/

 

/e

Never mind ;-) I now know why

[zycho42]

Never mind ;-) I now know why

 

Would you mind sharing? I have this issue with every v2 POST request...

 

Thx

[Moe]

Yeah no problem! I was just waiting for them to update the API page.

 

So I have this directory

cd ~/test/btsync/api

I then make the token request using curl like this:

curl -c cookie -u admin:password -X GET http://localhost:8888/api/v2/token

With the option -c I am writing the cookie to a file called cookie inside of ~/test/btsync/api

The -u option is for the basic authentication of the username and password set in my current config file found close by your binary. In my case it is in ~/.btsync and is just called config.

 

I then get a token response that looks like this:

pi@raspberrypi:~/test/btsync/api$ curl -c cookie -u admin:password -X GET http://localhost:8888/api/v2/token{ "data": { "token": "tokenishere" }, "method": "GET", "path": "/api/v2/token", "status": 0 }pi@raspberrypi:~/test/btsync/api$

You then take the token you get and put it to your POST request but also, which is the most important thing, you need to use the cookie you got with it with the option -b:

curl -b cookie -u admin:password -X POST -H "Content-Type: application/json" -d '{"type": 1}' http://localhost:8888/api/v2/secret?token=tokenishere

You will end up with 2 secrets

{ "data": { "rosecret": "hereismyrosecret", "secret": "hereismyrwsecret" }, "method": "POST", "path": "/api/v2/secret", "status": 0 }

The RO secret is longer than the RW secret and there is a trick you can use to get the encrypted secret!

Look here: http://forum.bittorrent.com/topic/25823-generate-encrypted-read-only-secret-without-api-key/?p=76262

 

Right now it only works with the way above but that is a known bug and is on the list on bugs to be fixed.

In a future release you will get a 3rd secret which is the encrypted secret.

 

You can also, if you add the RW key to one of your machines, go to the preferences of that share you added the key to and see a third key in the GUI which is the encrypted one.

The api is just not giving out the encrypted key..

[zycho42]

Yeah no problem! I was just waiting for them to update the API page since I didn't want to "leak" information that is not yet public.

 

 

Hey thanks for the quick response!

 

I'm still puzzeled as this was exactly what I was trying after decyphering the instructions in the api v2 docs (I'm pretty new to all this http and json stuff), but I still keep getting the invalid request response (I'm on btsync v2.2.0(100) btw). Here's what I'm doing:

$curl -c ~/btsync.cookie -u admin:pwd -X GET http://localhost:8888/api/v2/token

which yields:

{ "data": { "token": "tokenstring" }, "method": "GET", "path": "/api/v2/token", "status": 0 }

And then

$curl -b ~/btsync.cookie -u admin:pwd -X POST -H "Content-Type: application/json" -d '{"path":"/path/to/folder", "token": "tokenstring"}' http://localhost:8888/api/v2/folders

which returns

invalid request

I don't understand what's wrong here... Could you help me out?

 

Thanks a lot. 

 

[Moe]

You have to add the token to your request URL like in the example below

 

And how to add the folder is explained here: https://www.getsync.com/intl/de/api/docs#_folders_post

 

So AFAIK you have to make the request like this:

curl -b ~/btsync.cookie -u admin:pwd -X POST -H "Content-Type: application/json" -d '{"path":"/path/to/folder", "secret":"yoursecretgoeshere" }' http://localhost:8888/api/v2/folders?token=tokengoeshere

Make sure the folder exists on your filesystem, and if not you can add another value to the json request which is

"force" : "true"

That did work for me at least.

[zycho42]

That did work for me at least.

 

 

Ok thanks so much! After deleting the cookie and generating a new one it worked!

However, if I read the docs correctly passing the token should be possible via the url as well as via json:

When first connecting the developer should perform a GET /api/v2/token to retrieve asynchronizer token. This token must be added to all POST, PUT, PATCH and DELETE requests as one of the parameters as token=<token value> or for JSON request{ ... , "token" : "<token value>" ...}. Failure to include this token will cause an invalid request error to be returned. The developer will also need to return the session cookie on all requests.

 

Appearantly passing the token through JSON is not working just yet...

 

Thanks again for helping me out, I was stumped!

Edited September 13, 2015 by zycho42

[Moe]

Huh so I think I had an error in my commands and I have re-checked it and it did not work. It did not give me an error though!

 

 

So I think we are doing it right but it just does not work.

I'm gonna report it to the Team.

[zycho42]

As a slightly off-topic question: in a script, would it be safer to generate the token and cookie each time, or would you store and reuse them?

[Moe]

Ok so for reference to whovever is going to read all this:

Try to put a wrong password in the curl request.

 

I have a username and password set in my BitTorrent Sync config file so I have to call curl with -u

 

 

@zycho42: Take a look at the sample projects: https://github.com/bittorrent/sync_slack

You can get a hang of it and copy pasta stuff together to make a nice script.

And I definitely recommend using either Googles Go or Python for it.

[zycho42]

@zycho42: Take a look at the sample projects: https://github.com/bittorrent/sync_slack

You can get a hang of it and copy pasta stuff together to make a nice script.

And I definitely recommend using either Googles Go or Python for it.

 

I'll have a look at those sample projects. I'm doing this in python. Getting the session cookie to load in python is turning out to be not-so-simple, but calling curl through the shell gets it done. Anyway, getting waay off topic now.

 

I'll figure it out from here! :-)

 

Thx

[RomanZ]

@zycho42, @Moe,

I double checked that APIv2 is working fine in Sync 2.2.0. I was able to reproduce the issue once, when I miscopied the token - in this case I've got successfull call for GET method, and it failed for PATCH.

 

I would advise to track carefully HTTP packets content and responses using some tool (either use wireshark, or web browser plugins).

[Moe]

For when I don't get a response, no "invalid" error the curl -v output looks like this:

pi@raspberrypi:~/test/btsync/api$ curl -v -b cookie -u wrong_user_admin:password -X POST -H "Content-Type: application/json" -d '{"path":"/mnt/btsync/Moe/api/", "secret":"XXXXXXXXXXXXXXXXX" }' http://localhost:8888/api/v2/folders?token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX* About to connect() to localhost port 8888 (#0)*   Trying 127.0.0.1...* connected* Connected to localhost (127.0.0.1) port 8888 (#0)* Server auth using Basic with user 'wrong_user_admin'> POST /api/v2/folders?token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX HTTP/1.1> Authorization: Basic XXXXXXXXXXXXXXXXXXX> User-Agent: curl/7.26.0> Host: localhost:8888> Accept: */*> Cookie: GUID=QzCE1Uz1em5QoKyKgqRf> Content-Type: application/json> Content-Length: 78>* upload completely sent off: 78 out of 78 bytes* HTTP 1.1 or later with persistent connection, pipelining supported< HTTP/1.1 401 Unauthorized< Connection: close< Content-Length: 0< Content-Type: text/html* Authentication problem. Ignoring this.< WWW-Authenticate: Basic realm="BitTorrent Sync"< Cache-Control: no-cache<* Closing connection #0pi@raspberrypi:~/test/btsync/api$

The username should be admin and not wrong_user_admin.

If username is correct, everything is working like expected.