SocketTools provides a private cloud storage API and components for uploading and downloading shared data files which are available to your application. This is primarily intended for use by developers to store configuration information and other data generated by their application. For example, you can use it to store configuration settings or upload backup copies of critical application data.
The connection to the storage service is always secure, using TLS 1.2 and AES-256 bit encryption. There are no third-party services you need to subscribe to, and there are no additional usernames or passwords for you to manage. Access to the service is associated with an account which is created when you purchase a development license, and the security tokens are bound to the runtime license key used when initializing the API. You also have the option to compress and encrypt the data you store using the Encoding, Compression and Encryption APIs. This article provides technical details as to how the SocketTools cloud storage service works.
When you get started with the storage API, you’ll notice there is some different terminology used. This will provide an overview of that terminology, and compare it to common terms used with traditional protocols like FTP. When accessing an FTP server, you generally deal with directories, files, names and types (generally whether the file is binary or text). The storage API has similar concepts, but uses somewhat different terminology.
An application identifier (AppId) is a null terminated string which uniquely identifies your application. This string, used in conjunction with your runtime license key, is used to generate an access token. This token is used to access the storage container which contains the data you’ve stored.
It is recommended you use a standard format for the AppId which consists of your company name, application name and optionally a version number. Some examples of an AppId string would be:
It is important to note these two example IDs, although similar, reference two different applications. Objects stored using the first ID will not be accessible using the second ID. If you want to store objects which should be shared between all versions of the application, it is recommended you use the first form, without the version number. If you want to store objects which should only be accessible to a specific version of your application, then it is recommended you use the second form which includes the version number.
The AppId must only consist of ASCII letters, numbers, the period and underscore character. Whitespace characters and non-ASCII Unicode characters are not permitted. The maximum length of the string is 64 characters, including the terminating null character. It is not required for your application to create a unique AppId. Each storage account has a default internal AppId named SocketTools.Storage.Default. This AppId is used if a NULL pointer or an empty string is specified.
Storage containers are somewhat analogous to directories or folders in a file system. However, they are general purpose and designed to allow you to control how your application accesses the data that’s been stored. There are four container types which are defined by the API, and you can think of them as types of boxes or file cabinets which you store your data in.
It is important to keep in mind these containers are available to all users of your application; your program controls who has access to any particular data file. Your users will not be able to “browse” any of the containers unless you specifically provide that capability by implementing it in your own code. There is no public access to any of the data which you upload, and our service does not use an open API accessible by third parties.
The global storage container is available to all users of your application. Any data stored in this container is available to everyone who uses your software. Unless you have a specific need to limit access to the data to a specific user or group of users, this is the recommended container you use to store data.
The domain storage container is limited to users in the same local domain, defined either by the name of the domain or workgroup assigned to the computer system. This can provide a kind of organization wide storage, but it does depend on the domain being unique. For example, if you are using domain storage for your application, and you have multiple customers who have systems that are part of the default “Workgroup” domain, they would all share the same container. If the domain or workgroup name changes, then data stored in the container would no longer be available.
The local machine storage container is associated with the physical computer system your application is running on. The machine is identified by unique characteristics of the system, including the boot volume GUID. Data stored in this container can only be accessed from the application running on that particular system. If the operating system is reinstalled, the machine ID will change and data stored in this container would no longer be available.
The current user storage container is associated with the current user who is using your application. The user identifier is based on the Windows Security Identifier (SID) assigned to the account when it’s created. If the user account is deleted, the data stored in this container will no longer be available to the application. Another user on the same computer system would not be able to access the data in this container.
In most cases, we recommend using global storage unless you have a specific reason to use a different container type. The reason for this is that global storage is available for all instances of your application, regardless of what system it is installed on. If you want to restrict information to a specific user, you can include individually identifiable information (such as a customer number) in the label you use to identify the objects. For example, if you want to store an individual configuration file for a specific customer, you could construct labels that look like this:
In this example, the customer numbers are unique and therefore the labels will refer to two different objects, even though the base name is “UserPref.xml” in both cases. Because there are no external endpoints to the objects you store (in other words, someone with a web browser cannot simply browse or search for what you’ve stored), only your application has access to this information. If the data you’re storing is sensitive, you can also take the extra step of encrypting it using a passphrase unique to your individual customers. SocketTools provides easy-to-use encryption capabilities that supports strong encryption using AES-256.
If you decide to use a different storage container for your data, you should make sure it’s data that can be easily recreated by your application, such as configuration settings that would revert to defaults. This is because the data your application stores will be tied to the specific domain, computer system or user. If the domain changes, or the system is reinstalled, then access to the data stored in those containers will be inaccessible.
Storage objects are similar to files in a file system. They are discrete blocks of data, associated with a label (name), have attributes and are associated with a particular content type. However, an object does not need to be an actual file on the local system. For example, you could store an object which is a string, a pointer to a structure, or any block of memory. You could also just store a complete file as an object. Unlike files, you cannot perform partial reads of an object or “seek” into certain parts of a stored object. Of course, you can download an object, either in memory or to a local file, and perform whatever operations you require on the data.
Object labels are similar to file names, and are a way to identify a stored object instead of using its internal object ID. However, there are some important differences. The most significant difference is that, unlike Windows file names, labels are case-sensitive. An object with the label “AppConfig” is considered to be different than one with the label “appconfig”. Labels can contain Unicode characters, but they cannot contain control characters.
You can also use forward slash or backslash characters in the label, but it’s important to note objects are not stored in a hierarchical structure. Your application can store objects using a folder-like structure, but it’s not something which is enforced by the API.
Each object your application stores is associated with a media type (also called a content type) which identifies the object’s data. This uses the standard MIME media type designations, such as “text/plain” or “application/octet-stream”. Your application can explicitly specify the media type you want to associate with the object, or you can have the API choose for you, based on the contents of the object and using the label as a hint for what it may contain. For example, if you create an object with the label “AppConfig.xml” and it contains text, then the API will select “text/xml” as the default media type.
To get started with the SocketTools cloud storage service, download an evaluation copy of SocketTools 10 and review the Frequently Asked Questions. The Library Edition includes a complete suite of APIs to create and manage your stored objects. The .NET Edition and ActiveX Edition include components that are similar in functionality to the HTTP components. If you’re already familiar with the SocketTools HTTP components, the WebStorage component was designed to work in a similar way with a very low learning curve.
An evaluation license gives you a limited amount of free storage to test with, and when you purchase a license that storage allotment is automatically increased. And, of course, if you have any questions on how to use the service, we provide free technical support.