Plans for the API key?

[Decipher]

So I mentioned this in another thread, but I think it's probably worthy of it's own thread:

 

My Drupal modules that I'm working on for the BTSync API all currently require that the server the user is running their Drupal site on is running BTSync configured with an API key.

 

My concern is that only people with an API key are going to be able to use my modules as currently that means they have to apply for developer status.

 

What is the plan in the future? Will the API key not be necessary in future releases? Or should a developers key be encoded into their application?

 

Given that Drupal code is open source, embedded my key would essentially be the same as providing my key to others, so it doesn't seem likely to be an ideal solution, so I'm hopping the plan is that the API key will eventually not be required for use of the BT Sync.

 

Otherwise, all my modules will have an extremely high barrier to entry.

[kos13]

This is very interesting use case and a short answer - you are right, there will be issues in using API key in this way.

 

And seems you are right that API key needs to be embedded in binary in some way. However then we will face issue with having different binaries for each developer. That means update of binaries will be hard and messy.

 

We are going to work on this and will come up with some solution.

[avladev]

Can you tell what is the purpose of the api key? It's not checked online so I think it only activates the api.

[kos13]

It is checked if computer is online. 

[Decipher]

With other API based things, the client (not the server) is where the API key is configured, and users are allowed to apply for API keys not just developers.

 

Is there a chance that this will happen? Otherwise I will have to recommend users apply to become developers just so they can use my Drupal modules on their own servers, which may not be exactly what you had intended, but if I am restricted in this way what choice do I have?

[kos13]

I think this is a best solution for now. Not everything is set in stone and we are listening to our users.

[lolcat]

This seems so incredibly silly. If I were to bundle BTSync in some malicious software, wouldn't I just wrap the network connections in such a way that the connections goes to another server than yours? Or simply block the API check and the tracker alltogether? I realize you are probably worried about liability for running a torrent tracker that through the API could probably be abused for a bunch of malicious uses (hosting illegal content encrypted, stealing documents, pictures or other files, piracy). If you combine that with a botnet you get potentially scary issues for whomever is hosting the tracker. As I see it all of this is a result of keeping the software centralized. The central tracker is causing all these problems, either eliminating it through better DHT and local peer exchange, or allowing everyone to host their own trackers could solve it.

It seems pointless to limit the ability to use features that are ready for the users. The idea that Bittorent inc holds a killswitch for my sync is also questionable.

[LazyWolf]

From my experience it would be extremely simple to load the executable up in olly and bypass any checks that are built in, then just distribute that with my application. These limitations only restrict legitimate developers and make building any thing using btsync a waste of time and energy.

Sent from my SCH-I545 using Tapatalk

[lolcat]

From my experience it would be extremely simple to load the executable up in olly and bypass any checks that are built in, then just distribute that with my application. These limitations only restrict legitimate developers and make building any thing using btsync a waste of time and energy. Sent from my SCH-I545 using Tapatalk

 

Agreed, bypassing the limitations seems fairly simple. It seems even the webUI could easily be modified to remove restrictions of features.

[billerr]

For the development of "dumb" clients (i.e. clients that only function as a UI for a remotely installed server), the current implementation is a no-go. End users shouldn't be expected to apply for a developer API key just to access their btsync servers remotely.

 

A more elegant implementation would be to either rely on just a username/password combination for access control (if an app goes rogue, just change password) or on an API key generated by the btsync server providing access to GUI clients (think SickBeard/CouchPotato - revoking access by re-generating the API key).

 

The second way could be implemented in an even more granular way: generate and manage different API keys for each client wanting to connect and revoke their access independently. This could even be hidden behind a more user-friendly "Authorize/Revoke" UI.