Api date formats, Authentication and permissions – HP StoreAll Storage User Manual

Page 155

Advertising
background image

error. Any request with the version field and 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.

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 or groups configured for
this HTTP share, except for anonymous shares.

For file content transfer operations (see

“File content transfer” (page 156)

), 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 and metadata queries, the user must also have file system
permission to navigate to the directory containing the file or directory defined in the URI. If the user
has that permission, custom metadata assignment and queries will be allowed regardless of the
ownership or permissions of the file or directory. If a directory is specified, the operations will be
allowed on all files and subdirectories regardless of their ownership and permissions. 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
as the Linux user “daemon” and group “daemon” (daemon:daemon), since that is the user the
HTTP Server acts as, for anonymous operations.

For retention properties assignment, the user must also have file system permission to navigate to
the directory containing the file defined in the URI. Additionally, the user must be the owner of the
file according to the file system’s properties for the file’s owning user. If these permissions are not
satisfied, the operation will not be allowed. Retention properties can never be assigned by
anonymous users on anonymous shares, but they can be assigned by authenticated users with
sufficient permissions, on anonymous shares.

Component overview

155

Advertising