Api date formats, Authentication and permissions – HP StoreAll Storage User Manual
Page 220
The version field is recommended, but not required. In the syntax descriptions, it is surrounded by
square brackets to indicate that it is optional.
The current API is not fully backward compatible. That is, changes to this API might require client-side
syntax changes to perform some operations. In the new API, the version has been increased to the
next value. Any request without the version field might no longer work as desired or it might return
an error. Any request with the version field set to a value less than or equal to the current version,
is handled correctly by the new API version unless the capability has been removed or is beyond
the support lifetime of the product.
Default version
Accepted version
Release
1
1
Releases until 6.3
2
2
Releases after 6.3 (to 6.5)
API date formats
All date/time values accepted by the API in HTTP requests must be in seconds only (no nanoseconds)
since the UNIX epoch start point, which is:
1 Jan 1970 00:00:00 UTC
In the following example, the user provided the number of seconds that have occurred between
the UNIX epoch and April 17, 2012, 06:09:22 UTC/GMT as the date and time value in an HTTP
request:
1334642962
All dates and times provided in API HTTP responses are in seconds and nanoseconds since the
UNIX epoch start point. For example, the following date/time value as returned by the StoreAll
REST API in a JSON HTTP response:
1334642962.678934883
This signifies the number of seconds since UNIX epoch on April 17, 2012, 06:09:22.678934883
UTC/GMT.
Some of the time fields stored in the inode of the file in the StoreAll file system store a granularity
of seconds only, no nanoseconds. In these cases the nanoseconds portion is returned as zeros (for
example, 1334642962.000000000).
Some of the time fields stored in the metadata database store a granularity of microseconds instead
of nanoseconds. In these cases, the last 3 digits of the nanoseconds portion is returned as zeros
(for example, 1334642962.865449000).
Authentication and permissions
Any user accessing the API must authenticate as one of the valid users listed in the configuration
of the HTTP share, except for anonymous shares, which allow any user access. If no users are
listed in the HTTP share configuration and it is not an anonymous share, then any user, who can
be authenticated according to the StoreAll authentication settings for the cluster, can access the
share as read-write.
For file content transfer operations (see
“File content transfer” (page 221)
), including file upload,
download, or deletion, the user must also have permission to perform the file system operation, as
defined by the permissions and ownership of the file and its containing directories. Anonymous
users on anonymous shares can only operate on files that an anonymous user has uploaded using
the HTTP share.
For custom metadata assignment, the user must also have permission to navigate/execute to the
directory in the path containing the file as well as write permission for the file itself. Custom
metadata is stored only in the Express Query database and is not stored with the file or its inode
on the file system. An anonymous user on an anonymous share must have this navigate permission
220 HTTP-REST API file-compatible mode shares