It’s been a few months since our last “What’s New In B2” blog post, so we wanted to highlight some goings on and also introduce a new B2 feature!
Reintroducing: Java SDK + Compute Partnerships
We wanted to highlight the official Backblaze B2 Java SDK which can be found in our GitHub repo. The official Java SDK came out almost a year ago, but we’ve been steadily updating it since then with help from the community.
We’ve also announced some Compute Partnerships which give folks all the benefits of Backblaze B2’slow-cost cloud storage with the computing capabilities of Packet and ServerCentral. Backblaze B2 Cloud storage has directly connected to the compute providers, which offers customers low latency and free data transfers with B2 Cloud Storage.
Application Keys
Application keys give developers more control over who can do what and for how long with their B2 data. We’ve had the B2 application key documentation out for a while, and we’re ready to take off the “coming soon” tag.
What are Application Keys?
In B2, the main application key has root access to everything and essentially controls every single operation that can be done inside B2. With the introduction of additional application keys, developers now have more flexibility.
Application keys are scoped by three things: 1) what operations the key can do, 2) what path inside of B2 that key can take, and 3) for how long it has the ability to do so. For example you might use a “read-only” key that only has access to one B2 bucket. You’d use that read-only key in situations where you don’t actually need to write things to the bucket, only read or “display” them. Or, you might use a “write-only” key which can only write to a specific folder inside of a bucket. All of this leads to cleaner code with segmented operations, essentially acting as firewalls should something go awry.
Use Cases for Application Keys
One example of how you’d use an application key is for a standard backing up operation. If you’re backing up an SQL database, you do not need to use your root level key to do so. Simply creating a key that can only upload to a specified folder is good enough.
Another example is that of a developer building apps inside of a client. That developer would want to restrict access and limit privileges of each client to specific buckets and folders — usually based on the client that is doing the operation. Using more locked-down application keys limits the possibility that one rogue client can affect the entire system.
A final case could be a Managed Service Provider (MSP) who creates and uses different application key for each client. That way, neither the client nor the MSP can accidentally access the files of another client. In addition, an MSP could have multiple application keys for a given client that define different levels of data access for given groups or individuals within the client’s organization.
Note: If you are using a third party integration with B2, please check with the integration provider for appplication key compatibility.
We Hope You Like It
Are you one of the people that’s been waiting for application key support? We’d love to hear your use cases so sound off in the comments below with what you’re working on!
