Restricted Data with SOD
Access to restricted data at the DMC is done using code from the DMC embedded within SOD 2.2.3 and later. Earlier versions of SOD could not access restriected data at the DMC, although they could access restricted data at other servers. The only action that needs to be taken by a user that wishes to access restricted data with SOD is to specify the passwords that will be sent to the DMC. There are two ways of specifying passwords, in a props file or in a separate password file that is specified in the props file. More information about restricted data at IRIS can be found here: http://www.iris.edu/data/restricted.htm.
Passwords for the DMC seismogram server are of the form:
The password is a short secret string and the email address identifies an authorized user. This information would normally be issued by the DMC for a given network to the PIs for that network. For example:
These password properties would be placed in a file, one per line, and the filename passed to SOD using the -p option. Other properties, such as log4j logging are set via the same method. For example, if myPasswords.prop contained the above password line, then you would run SOD with:
sod -p myPasswords.prop -f myRecipe.xml
The alternative is to place the passwords into a text file similar to those used by other DMC client applications such as Vase and JWeed. Each line of the external authentication file looks like the following:
XX 2002 2005 myPasswd email@example.com
The name of this file is added to the same prop file above with a line like:
This format may be easier if you make use of these other DMC clients and only want to have a single password file.
Note that one source of confusion is that SOD does not generate an error if you try to access restricted data without a password, or with an incorrect password. This is because the server responds with "sorry I don't have any data" in both the case of there really not being any data and in the case of data existing, but being restricted. Given that restricted data is something of a special case, this seems the proper response to avoid useless error messages to the vast number of users who are not trying to access restricted data, but inadvertently request data from a restricted network.