File Storage

Certain File Storage names have special meanings.

empty

An empty-name file is retrieved via HTTP when no file name is specified in the Access URL, such as http://server:port/~username/, or http://server:port/~username, or http://server:port/~username/subfolder/

In this case, a file with a predefined name is retrieved. This predefined name is set as an Account Setting, and is usually set to default.html. So, an HTTP retrieval request for the http://server:port/~username/subfolder/ URL produces the same result as the http://server:port/~username/subfolder/default.html request.

freebusy.vfb

This text file contains the user Free/Busy information. When the Account Main Calendar is modified with the CommuniGate Pro MAPI module, XIMSS interface, or AirSync, CalDAV, or the WebUser Interface module, the file is deleted.
When this file is being accessed and it does not exist, the Server opens the Account Main Calendar, builds the Free/Busy information, and stores the information in the freebusy.vfb file.

If the Free/Busy information cannot be built (for example, if no Main Calendar Mailbox exists in the Account), the HTTP module generates an empty Free/Busy dataset and sends it to the client.

any_name.meta

these names are reserved and cannot be used.

private/logs/calls-yyyy-mmm

These text files are created and filled with the Signal Dialog objects. yyyy is a 4-digit year number, and mmm is a 3-letter month name.
Each file record has tab-delimited fields and contains information about one call made from or to the Account.

private/IM/userName@domainName.log

These text files contain Instant Messages send to and received from the userName@domainName address.
Each Instant Message is stored as one text line, with the following tab-delimited fields:

• time stamp (GMT): YYYYMMDDThhmmsss
• direction: < for incoming IMs, > for outgoing IMs
• deviceID: string - for "groupchat" messages - the sender or receiver device ID, an empty field otherwise
• body: string - the message body text, as a String object presentation.

Note: names starting with the tilda (~) symbol are used to specify Foreign Files, and, as a result, this symbol cannot be used as the first symbol of a file name.
Many Microsoft® products use names starting with the tilda symbol for temporary or service files. To avoid the problem, always use those products with Account Storage subdirectories, and not with the topmost Storage directory.

Virtual names do not specify actual files or folders in the File Storage, but they can be used to retrieve certain information.

index.wssp

This name is used for HTML-based File Storage management. Access to this resource requires authentication.

freebusy.wssp

This name is used to retrieve formatted Free/Busy information. The actual data is retrieved from the freebusy.vfb file (see above).

pubcal/calendarName.ics

These names are used to retrieve the contents of the specified Account Calendar Mailbox in the iCalendar format. This virtual files can be used to "publish" the Calendar information. The user must have the right to Select the specified Mailbox.

$DomainSkins, $ServerSkins, $ClusterSkins

These virtual directories provide access to the Domain-wide or to the Server-wide/Cluster-wide Skins. Each Skin is presented as a subdirectory, with the name $unnamed$ used for the "unnamed" Skins.
The Account must have the proper Access Rights to see and manage these directories.

$DomainPBXApp, $ServerPBXApp, $ClusterPBXApp

These virtual directories provide access to the Domain-wide or to the Server-wide/Cluster-wide Real-Time Application Environments. Language variants are presented as subdirectories.
The Account must have the proper Access Rights to see and manage these directories.

Each file and file directory can have an set of attributes or meta-information.

For example, the Betty.jpeg file contains meta-information such as the location where the photo was taken, comments, etc.

Each attribute is an XML element.

Some attributes are "protected" - they can be modified only by the Account owner, the System or Domain Admin or if the user is granted the "Administer" Access Right to that file or file directory.

The CommuniGate Pro Server maintains an Access Control List (ACL) for every Storage file or file directory. This list is stored as an <ACL> protected File Attribute.

The Access Control Lists are used to control the Foreign File Access feature that allows Account users to access File Storage in other Accounts.

All files and file directories in an Account File Storage located outside the private directory are open for "list" (directories) and "read" operations for any Account user, as well as for non-authenticated users. For example, these files can be accessed via unauthenticated HTTP requests, and they can be used as a Personal Web Site.

The Account owner has all access rights to all Account Storage files and directories.

A Server Administrator with the All Domains access right has all access rights to all files in all Server or Cluster Accounts.

Domain Administrators with the CanViewWebSites access right have all access rights for all files in their Domain Accounts.

The Account owner can grant certain limited file access rights to other users, using the Access Control Lists.

The following File Access Rights are supported:

l (List, file directories only)

If you grant a user the List access right, that user will be able to see the content of this file directory.

d (Delete, file directories only)

If you grant a user the Delete access right, that user will be able to remove files and empty file sub-directories from this file directory.

r (Read)

If you grant a user the Read access right to a file, that user will be able to read this file and its unprotected attributes. If you grant a user the Read access right to a file directory, that user will be able to read all files in this directory for which the Access Control Lists are not specified.

w (Write)

If you grant a user the Write access right to a file, that user will be able to write to this file and to modify its unprotected attributes. If you grant a user the Write access right to a file directory, that user will be able to write to all files in this directory for which the Access Control Lists are not specified, and the user will be able to create new files in this directory.

a (Administer)

If you grant a user the Administer access right, that user will be able to modify the file ACL and other "protected" File Attributes.

When a file directory is created, the ACL of the outer directory (if any) is copied to the newly created directory.

Read access to files and List access to directories inside the private directory can be granted to other CommuniGate Pro users and external "guests", using the protected <accessPwd> File Attribute.

Each <accessPwd> attribute should have a <key/> element containing a random string - the access-password. It is recommended to add <EMail/> element(s) with the E-mail address(es) of the users to whom this access-password has been sent.

Example:

<accessPwd>
  <key>dyf984897498ih12ui3u-3y887</key>
  <EMail realName="User Name">user1@domain1.dom</EMail>
  <EMail>user2@domain2.dom</EMail>
</accessPwd>

When this attribute is added to the private directory, it enables an alternative access path to all files within that directory and its subdirectories:

protected/pwd/access-password/

If this attribute is added to the private/dir1/dir2 directory, it enables an alternative access path to all files within that directory and its subdirectories:

protected/dir1/pwd/access-password/dir2/

If the XML attribute listed in the example above is added to the private/dir1/dir2 directory file attributes, the user can compose a Personal Site URL using the alternative path:

http://server:port/~username/protected/dir1/pwd/dyf984897498ih12ui3u-3y887/dir2/file.name

The user then can send this URL to user1@domain1.dom and user2@domain2.dom and other addresses. The recipients can access this file.name file by following this link.

The user can revoke this access right by removing this <accessPwd/> attribute.

Alternative file paths can be used in FTP and TFTP protocols, and in all other CommuniGate Pro components that access the Account File Storage.

Users can manage their Account File Storage using a Web browser. There are two methods to access the File Storage administration pages:

• By opening a WebUser Session, and using the Files link in the WebUser Interface navigation panel.
• By opening the Index.wssp file in their own personal Web site:
  http://domain.dom:8100/~username/Index.wssp
  A browser will present a Login (authentication) dialog box, and the users should enter their Account names and passwords in order to open the Web site administration page.

Server administrators with the All Domains access right and Domain administrators with the CanAccessWebSites access right can access File Storage in other Accounts.

Server and Domain administrators can access File Storage of any Account using the WebAdmin Interface: the Account management pages have the Files link in their navigation panels.

All management methods use similar HTML pages for File Storage administration, see the WebUser Interface Files section for the details.

File Storage data can be modified using the HTTP 1.1 PUT, DELETE, and MOVE methods. Some HTML design tools can use these methods to upload files to the server.

These HTTP requests should contain the Authentication information: the Account name of the File Storage owner or the Account name of a Server/Domain Administrator, and the password for that Account.

CommuniGate Pro allows each user to be presented on the World Wide Web with a personal Web site. The URL for the accountname@domainname Account File Storage is:
<http://domainname:port/~accountname>   where the port is the WebUser port.
For example, the jsmith@client1.com account has a personal Web site at:
<http://client1.com:8100/~jsmith>

Personal Web sites use the same HTTP port as the WebUser Interface (the port 8100 by default).

In addition to the ~ prefix, an alternative prefix can be specified in the Domain Settings. The alternative prefix can be an empty string.

All Routing Rules discussed in the Access section apply to the personal Web site URLs, so Account and Domain aliases can be used in the personal Web site URLs.

Personal Web sites can be accessed without a prefix, using just the server part of the URL string. When the CommuniGate Pro server receives an HTTP connection on the its WebUser port, it uses the special Domain Routing procedure.

If the domain name user.domain.com has a DNS A-record pointing to the IP address of the CommuniGate Pro server, and the CommuniGate Pro Router has the following record:
<LoginPage@user.domain.com> = userA@domainB.com
and the Account userA exists in the CommuniGate Pro Domain domainB, then the URL http://user.domain.com/ can be used to access the personal Web site (File Storage) of the userA@domainB.com Account.

File Storage must not contain any index.wssp file. This name is reserved for the File Storage Management forms.

The home (default) page of a personal Web Site should have the default.html name. This means that when the file name is not specified explicitly, the default.html name is assumed. If a File Storage has folders (subdirectories), then the request with the http://server:port/prefix user/folder/ URL retrieves the default.html file from that subdirectory.

The name of the default page is specified as an Account Setting and it can be modified on the per-Account basis.

File Storage data can be accessed, modified, and managed using the CommuniGate Pro FTP module. When an Account user connects to the FTP module, the FTP "root directory" as well as the "current directory" are set to the Account File Storage top directory.

File Storage data can be accessed, modified, and managed using the CommuniGate Pro HTTP module WebDAV extension.
use http://server:port/WebDAV/ or https://server:port/WebDAV/ URLs to configure a WebDAV client.

Access to the /WebDAV/ realm requires authentication, and the authenticated Account and its Domain must have the WebSite Service enabled.
This realm presents the authenticated Account File Storage top directory.

The File Access WebDAV protocol works over the HTTP protocol, using the HTTP User Module. Open the HTTP User Module settings, and find the Sub-Protocols panel:

Sub-Protocols
FileDAV:	Crashes OnlyFailuresMajor & FailuresProblemsLow LevelAll Info

Use the FileDAV Log setting to specify the type of information the File Access WebDAV module should put in the Server Log.

The File Access WebDAV module records in the System Log are marked with the FileDAV tag.

The CommuniGate Pro allows an Account user to access File Storage in other Accounts.
Access to these foreign Files (also called shared Files) is controlled via the File Access Rights.

To access a file or a file directory in a different Account, the file name should be specified as ~accountname/filename. For example, to access the images/pict01.jpg file in the Boss Account, the file name should be specified as ~Boss/images/pict01.jpg .

If there are several local Domains on the Server, files in a different Domain can be accessed by specifying full Account names. To access the images/pict01.jpg file in the Account designer in the client.com Domain, the file name should be specified as ~designer@client.com/images/pict01.jpg.

Account names specified after the "~" sign are processed with the Router, so Account Alias names can be used instead of the real Account names, and all Routing Table rules are applied.

Each Account has a file subscription set - a set of file and/or file directory names.

This list is maintained with various clients. Usually, it contains the names of foreign file directories, such as ~accountName/dir1/dir2/, letting clients show some preselected foreign file directories.