This documentation space is deprecated. Please make all updates to DuraCloud documentation on the live DuraCloud documentation space.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

This document details some of the considerations of concern to a DuraCloud administrator.

Naming restrictions

  1. Space names
    1. The following restrictions apply to user-defined space names
      • only lowercase letters, numbers, periods, and dashes
      • no adjacent pair of "-" and/or "."
      • no number immediately following the last "."
      • between 3 and 42 characters
      • must start with a letter
      • may not end with a dash
    2. Note: Users can provide space names through the REST-API that do not follow these conventions, but the space actually created will have a different name under the covers.
  2. Reserved space names
    1. Due to some specific operations exposed through the durastore REST-API, the following names are unavailable as user-defined space names
      • init
      • stores
      • spaces
      • security
      • task
  3. Content object names
    1. The only restrictions are that a content object name
      • cannot include a question mark '?' character
      • cannot include a reverse solidus (backslash) '\' character
      • is limited to 1024 bytes (byte count is checked after URL and UTF-8 encoding)

Access Control Lists (ACLs)

Prior to DuraCloud v1.3.1, control over access to spaces was limited to setting the space-level permission to either OPEN or CLOSED. An OPEN space permitted anonymous reads of content within that space, whereas a CLOSED space disallowed any reads or writes of content within that space by unauthenticated users. As of DuraCloud v1.3.1, the space-level access control mechanisms have been richened.

  1. Users and Groups
    1. Access is granted to users, groups, or combinations thereof
    2. Users are those with credentials to access an account
    3. Groups are collections of users that are created in the Management Console
  2. Rights
    1. When assigning a space ACL, users and/or groups are granted one of two rights
      1. READ allows reading any content within that space
      2. WRITE allows reading, adding, and modifying any content within that space
  3. Public (anonymous) Access
    1. There is a special group named 'public' that can only be granted READ access to a space
    2. If the 'public' group has READ access, then unauthenticated (anonymous) reads of content are permitted on that space
  4. Use
    1. REST API can be used to programmatically create, update, and delete space ACLs
    2. DurAdmin provides authorized users to update space ACLs in the web interface
  • No labels