While most of the API functions employ an internal authentication strategy (the credentials section of the request body), a few require HTTP Basic Authentication instead. This allows configuring preexisting tools, which were not specifically designed to use this API, to use basic services of this API.
For example, the CloudForge Activity Streams data formats and functions are based on the industry standard Activity Streams formats and functions. The standards allow for HTTP Basic Authentication, but not for the proprietary CloudForge credentials.
CloudForge authentication requires three values:
HTTP Basic Authentication, on the other hand, involves only two values,
Suppose user Joe Jetson works for the Kitty Kind Katfood Company, with
- domain kittykind
- login joe
- password miaou
Then to use HTTP Basic Authentication with the CloudForge API, he should provide HTTP Basic Authentication credentials of
- userid kittykind_joe
- password miaou
The details of how to program HTTP Basic Authentication will depend on the chosen programming environment, but they basically fall into two possible techniques.
Nearly any REST client packge will allow you to embed the HTTP Basic Authentication credentials in the URL:
Since the CloudForge API is accessed using
which encrypts the URL as well as the message body, the
credentials are secure while in transit over the Internet.
The HTTP standard also defines an Authorization header, which can be used to carry the HTTP Basic credentials instead of the URL. This provides basically the same security while in transit through the Internet, but may be more convenient for the application's internal displays.
For example, the application may have a dialog where the user can enter credentials for a particular connection:
- For URL https://api.cloudforge.com/
- Login: ___________________________
- Password: _______________________
In such a dialog, the URL is presented in ordinary, readable text, but the password (at the least) is not actually displayed, even when typed; instead, something like a line of dots is displayed. This is much easier to program if the developer can keep these three strings separately, rather than slicing up the URL before displaying.
Here are examples of each approach using the Ruby RestClient library.