Site Stacker API

Example Authenticated Site Stacker API Request

The Authentication Header

The Site Stacker API uses the standard HTTP Authorization header to pass authentication information. 

(The name of the standard header is unfortunate because it carries authentication information, not authorization). 

Under the Site Stacker authentication scheme, the Authorization header has the following form:

Any Site Stacker user can have an access key ID and secret access key that are generated from the Users component in 

admin, by right clicking a user > API Access and click on Generate API Keys, as shown below:

For request authentication, the AccessKeyId element identifies the access key ID that was used to compute the signature 

and, indirectly, the user making the request. The Signature element is the RFC 4868 HMAC-SHA256 of selected 

elements from the request, and so the Signature part of the Authorization header will vary from request to request. 

If the request signature calculated by the system matches the Signature included with the request, the requester will 

have demonstrated possession of the Site Stacker secret access key. The request will then be processed under the identity,

and with the authority, of the user to whom the key was issued.

Following is pseudogrammar that illustrates the construction of the Authorization request header. (In the example, \n 

means the Unicode code point U+000A, commonly called newline).

HMAC-SHA256 is an algorithm defined by RFC 4868 - Using HMAC-SHA-256. The algorithm takes as input two 

byte-strings, a key and a message. For Site Stacker request authentication, use your Site Stacker secret access key 

(SecretAccessKey) as the key, and the StringToSign as the message. The binary output of HMAC-SHA256 is then 

converted to a hexadecimal representation, called the hex digest, which is the Signature.

Positional HTTP Header StringToSign Elements

All elements of StringToSign (Content-Type, Date) are positional in nature. StringToSign does not include the names 

of these headers, only their values from the request. If a positional header called for in the definition of StringToSign is 

not present in your request (for example, Content-Type is optional for PUT requests and meaningless for GET requests), 

substitute the empty string ("") for that position.

Time Stamp Requirement

A valid time stamp (using the HTTP Date header or an ss-date alternative) is mandatory for authenticated requests. 

Furthermore, the client timestamp included with an authenticated request must be within 5 minutes of the Site Stacker 

system time when the request is received. If not, the request will fail with the RequestTimeTooSkewed error code. 

The intention of these restrictions is to limit the possibility that intercepted requests could be replayed by an adversary. For 

stronger protection against eavesdropping, use the HTTPS transport for authenticated requests.

Some HTTP client libraries do not expose the ability to set the Date header for a request. If you have trouble including 

the value of the 'Date' header in the canonicalized headers, you can set the timestamp for the request by 

using an 'ss-date' header instead. The value of the ss-date header must be in one of the RFC 2616 formats 

(http://www.ietf.org/rfc/rfc2616.txt). When an ss-date header is present in a request, the system will use this date when 

computing the request signature.

Authentication Examples

The examples in this section use the (non-working) credentials in the following table.

In the example StringToSigns, formatting is not significant, and \n means the Unicode code point U+000A, 

commonly called newline. Also, the examples use "+0000" to designate the time zone. You can use "GMT" to designate 

timezone instead, but the signatures shown in the examples will be different.

Example Object GET

Request:

StringToSign:

Example Object POST

Request:

StringToSign:

Note the Content-Type header in the request and in the StringToSign.