mirror/netcdf-c
2
0
Fork 0
mirror of https://github.com/Unidata/netcdf-c.git synced 2025-04-12 18:10:24 +08:00
Code Issues Packages Projects Releases Wiki Activity

- clean up the dfile.c confusion about NC_64_BIT_OFFSET

Browse Source 
- sync oc2 with  master for https://DennisHeimbigner@github.com/Unidata/oc.git
- Cleanup auth.html documentation.
- Cleanup obsolete documentation.
This commit is contained in:
dmh 2015-10-24 21:45:13 -06:00
parent 8d58d5d34f
commit 7480d7d97d
14 changed files with 1338 additions and 2083 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/Makefile.am
View File

@ -10,8 +10,8 @@ EXTRA_DIST = netcdf.m4 DoxygenLayout.xml Doxyfile.in footer.html \
architecture.dox internal.dox windows-binaries.md \
building-with-cmake.md CMakeLists.txt \
groups.dox install.md notes.md install-fortran.md \
all-error-codes.md cmake_faq.md credits.md auth.md.in auth.md \
software.md ocauth.md
all-error-codes.md cmake_faq.md credits.md software.md \
auth.html
# Turn off parallel builds in this directory.
.NOTPARALLEL:
@ -54,9 +54,6 @@ doxyfile.stamp:
CLEANFILES = doxyfile.stamp html latex man
auth.md: auth.md.in ocauth.md
cat auth.md.in ocauth.md > auth.md
# This builds the docs from source, if necessary, and tars up
# everything needed for the website. Run this and copy the resulting
# tarball to the /contents/netcdf/docs directory to update the on-line
@ -64,3 +61,14 @@ auth.md: auth.md.in ocauth.md
web-tarball: doxyfile.stamp
cd html; tar cf ../netcdf_docs.tar *
gzip -f netcdf_docs.tar
# When oc2/auth.html.in is changed, you should generate auth.html
# using the following process.
auth::
cat ${top_srcdir}/oc2/auth.html.in \
cat ${top_srcdir}/oc2/auth.html.in \
| sed -e '/<OC>/d' \
| sed -e 's|^<NC>||' \
| sed -e 's|zz|netcdf|g' -e 's|ZZ|netCDF|g' \
| sed -e '/stylesheet/r${top_srcdir}/oc2/oc.css' -e '/stylesheet/d' \
>auth.html

185
oc2/ocauth.html → docs/auth.html
View File

@ -1,14 +1,35 @@
<!- Copyright 2014, UCAR/Unidata and OPeNDAP, Inc. -->
<!- Copyright 2015, UCAR/Unidata and OPeNDAP, Inc. -->
<!- See the COPYRIGHT file for more information. -->
<html>
<head>
<style>
.break { page-break-before: always; }
body { counter-reset: H2; font-size: 12pt; }
h1.title {
font-size: 18pt;
text-decoration: underline;
}
div.subtitle {
}
.subtitle h1 {
font-size: 14pt;
margin-top: 0;
margin-bottom: 0;
}
h1.toc {
font-size: 16pt;
text-decoration: underline;
}
h1.appendix {
font-size: 14pt;
}
h2:before {
content: counter(H2) " ";
counter-increment: H2;
}
h2 { counter-reset: H3; }
h2 { counter-reset: H3; text-decoration: underline; }
h3:before {
content: counter(H2) "." counter(H3) " ";
counter-increment:H3;
@ -18,21 +39,20 @@ h4:before {
content: counter(H2) "." counter(H3) "." counter(H4) " ";
counter-increment:H4;
}
h5 {font-size: 14pt; } /* For Appendices */
h6 {font-size: 16pt; } /* For Subtitles */
</style>
</head>
<body>
<center>
<h1>OC Authorization Support</h1>
<h6>Author: Dennis Heimbigner<br>
dmh at ucar dot edu</h6>
<h6>Draft: 11/21/2014<br>
Last Revised: 12/23/2014<br>
OC Version 2.1</h6>
</center>
<h1 class="title">netCDF Authorization Support</h1>
<div class="subtitle">
<h1>Author: Dennis Heimbigner</h1>
<h1>Address: http://www.unidata.ucar.edu/staff/dmh/</h1>
<h1>Draft: 11/21/2014</h1>
<h1>Last Revised: 10/24/2015</h1>
</div>
<h6 class="break"><u>Table of Contents</u></h6>
<h1 class="toc">Table of Contents</h1>
<ol>
<li> <a href="#Introduction">Introduction</a>
<li> <a href="#URL-AUTH">URL-Based Authentication</a>
@ -44,8 +64,8 @@ OC Version 2.1</h6>
<li> <a href="#ESGDETAIL">Appendix B. ESG Access in Detail</a>
</ol>
<h2 class="break"><a name="Introduction"><u>Introduction</u></a></h2>
OC can support user authorization using those provided by the curl
<h2><a name="Introduction">Introduction</a></h2>
netCDF can support user authorization using the facilities provided by the curl
library. This includes basic password authentication as well as
certificate-based authorization.
<p>
@ -57,7 +77,7 @@ The libcurl authorization mechanisms can be accessed in two ways
<i>.daprc</i> or <i>.dodsrc</i>
</ol>
<h2 class="break"><a name="URL-AUTH"><u>URL-Based Authentication</u></a></h2>
<h2><a name="URL-AUTH">URL-Based Authentication</a></h2>
For simple password based authentication, it is possible to
directly insert the username and the password into a url in this form.
<pre>
@ -67,23 +87,21 @@ This username and password will be used if the server asks for
authentication. Note that only simple password authentication
is supported in this format.
Specifically note that <a href="#REDIR">redirection</a> based
authorization will not work with this.
authorization will not work with this because the username and password
will only be used on the initial request, not the redirection
<h2 class="break"><a name="DODSRC"><u>RC File Authentication</u></a></h2>
The oc library supports an <i>rc</i> file mechanism to allow the passing
of a number of parameters to liboc and libcurl.
<h2><a name="DODSRC">RC File Authentication</a></h2>
The netcdf library supports an <i>rc</i> file mechanism to allow the passing
of a number of parameters to libnetcdf and libcurl.
<p>
The file must be called one of the following names:
".daprc" or ".dodsrc"
If both .daprc and .dodsrc exist, then
the .daprc file will take precedence.
<p>
Searching for the rc file first looks in the current directory
The rc file is searched for first in the current directory
and then in the home directory (as defined by the HOME environment
variable). It is also possible to specify a direct path using
the <i>-R</i> option to ocprint or using the <i>oc_set_rcfile</i>
procedure (see oc.h). Note that for these latter cases, the path
must be to the file itself, not to the containing directory.
variable).
<p>
The rc file format is a series of lines of the general form:
<pre>
@ -93,10 +111,11 @@ where the bracket-enclosed host:port is optional and will be discussed
subsequently.
<p>
The currently defined set of authorization-related keys are as follows.
The second column is the affected curl_easy_setopt option(s).
The second column is the affected curl_easy_setopt option(s), if any.
<table>
<tr><th>Key<th>curl_easy_setopt Option
<tr><td>HTTP.COOKIEJAR<td>CURLOPT_COOKIEJAR, CURLOPT_COOKIEFILE
<tr><th>Key<th>Affected curl_easy_setopt Options<th>Notes
<tr><td>HTTP.COOKIEJAR<td>CURLOPT_COOKIEJAR
<tr><td>HTTP.COOKIEFILE<td>CURLOPT_COOKIEJAR<td>Alias for CURLOPT_COOKIEJAR
<tr><td>HTTP.PROXY_SERVER<td>CURLOPT_PROXY, CURLOPT_PROXYPORT, CURLOPT_PROXYUSERPWD
<tr><td>HTTP.SSL.CERTIFICATE<td>CURLOPT_SSLCERT
<tr><td>HTTP.SSL.KEY<td>CURLOPT_SSLKEY
@ -104,36 +123,41 @@ The second column is the affected curl_easy_setopt option(s).
<tr><td>HTTP.SSL.CAINFO<td>CURLOPT_SSLCAINFO
<tr><td>HTTP.SSL.CAPATH<td>CURLOPT_SSLCAPATH
<tr><td>HTTP.SSL.VERIFYPEER<td>CURLOPT_SSL_VERIFYPEER
<tr><td>HTTP.SSL.VALIDATE<td>CURLOPT_SSL_VERIFYPEER, CURLOPT_SSL_VERIFYHOST
<tr><td>HTTP.CREDENTIALS.USERPASSWORD<td>CURLOPT_USERPASSWORD
<tr><td>HTTP.NETRC<td>N.A.<td>Specify path of the .netrc file
</table>
</ul>
<h3><u>Password Authentication</u></h3>
<h3>Password Authentication</h3>
The key
HTTP.CREDENTIALS.USERPASSWORD
can be used to set the simple password authentication.
This is an alternative to setting it in the url.
The value must be of the form "username:password".
See <a href="#REDIR">redirection authorization</a>
for important additional information.
<h3><u>Cookie Jar</u></h3>
<h3>Cookie Jar</h3>
The HTTP.COOKIEJAR key
specifies the name of file from which
to read cookies (CURLOPT_COOKIEJAR) and also
the file into which to store cookies (CURLOPT_COOKIEFILE).
The same value is used for both CURLOPT values.
It defaults to in-memory storage.
See <a href="#REDIR">redirection authorization</a>
for important additional information.
<h3><u>Certificate Authentication</u></h3>
<h3>Certificate Authentication</h3>
HTTP.SSL.CERTIFICATE
specifies a file path for a file containing a PEM cerficate.
This is typically used for client-side authentication.
<p>
HTTP.SSL.KEY is essentially the same as HTTP.SSL.CERTIFICATE
and should usually have the same value.
and should always have the same value.
<p>
HTTP.SSL.KEYPASSWORD
specifies the password for accessing the HTTP.SSL.KEY/HTTP.SSL.CERTIFICATE
file.
specifies the password for accessing the HTTP.SSL.CERTIFICAT/HTTP.SSL.key file.
<p>
HTTP.SSL.CAPATH
specifies the path to a directory containing
@ -144,66 +168,64 @@ is a boolean (1/0) value that if true (1)
specifies that the client should verify the server's presented certificate.
<p>
HTTP.PROXY_SERVER
specified the url for accessing the proxy:
(e.g.http://[username:password@]host[:port])
specifies the url for accessing the proxy:
e.g. <i>http://[username:password@]host[:port]</i>
<p>
HTTP.NETRC
specifies the absolute path of the .netrc file.
See <a href="#REDIR">redirection authorization</a>
for information about using .netrc.
<h2 class="break"><a name="REDIR"><u>Redirection-Based Authentication</u></a> </h2>
<h2><a name="REDIR">Redirection-Based Authentication</a> </h2>
Some sites provide authentication by using a third party site
to do the authentication. One example is
<a href="https://uat.urs.earthdata.nasa.gov">URS</a>,
the EOSDIS User Registration System.
to do the authentication. Examples include ESG and URS.
<p>
The process is usually as follows.
<ol>
<li>The client contacts the server of interest (SOI), the actual data provider
using, typically http protocol.
<li>The SOI sends a redirect to the client to connect to the URS system
using the 'https' protocol.
<li>The SOI sends a redirect to the client to connect to the e.g. URS system
using the 'https' protocol (note the use of https instead of http).
<li>The client authenticates with URS.
<li>URS sends a redirect (with authorization information) to send
the client back to the SOI to actually obtain the data.
</ol>
<p>
It turns out that libcurl uses the password in the .daprc file
It turns out that libcurl uses the password in the .daprc file &mdash; or from the url &mdash;
only for the initial connection. This causes problems because
the redirected connection is the one that actually requires the password.
This is where .netrc comes in. Libcurl will use .netrc for
the redirected connection. It is possible to cause libcurl to use
the .daprc password always, but this introduces a security hole.
the .daprc password always, but this introduces a security hole
because it may send the initial user+pwd to the redirection site.
In summary, if you are using redirection, then you must create a .netrc
file to hold the password for the site to which the redirection is sent.
<p>
The format of this .netrc file will contain content that
typically look like this.
<pre>
machine uat.urs.earthdata.nasa.gov login xxxxxx password yyyyyy
machine mmmmmm login xxxxxx password yyyyyy
</pre>
where the machine is the one to which the client is redirected
for authorization, and the login and password are those
needed to authenticate.
where the machine, mmmmmm, is the hostname of the machine to
which the client is redirected for authorization, and the
login and password are those needed to authenticate on that machine.
<p>
The .netrc file can be specified in two ways.
<ol>
<li> Specify the netrc file to liboc using the procedure in oc.h:
<pre>
oc_set_netrc(OClink* link, const char* file)
</pre>
(This is equivalent to the -N flag to ocprint).
<p>
<li> Put the following line in your .daprc/.dodsrc file.
The .netrc file can be specified by
putting the following line in your .daprc/.dodsrc file.
<pre>
HTTP.NETRC=&lt;path to netrc file&gt;
</pre>
</ol>
<p>
One final note. In using this, it is probable that you will
need to specify a cookie jar (HTTP.COOKIEJAR) so that the
One final note. In using this, it is almost certain that you will
need to specify a real cookie jar file (HTTP.COOKIEJAR) so that the
redirect site can pass back authorization information.
<h2 class="break"><a name="URLCONS"><u>URL Constrained RC File Entries</u></a></h2>
<h2><a name="URLCONS">URL Constrained RC File Entries</a></h2>
Each line of the rc file can begin with
a host+port enclosed in square brackets.
The form is "host:port". If the port is not specified
The form is "host:port".
If the port is not specified
then the form is just "host".
The reason that more of the url is not used is that
libcurl's authorization grain is not any finer than host level.
@ -214,8 +236,8 @@ Examples.
or
[fake.ucar.edu:9090]HTTP.VERBOSE=0
</pre>
If the url request from, say, the <i>oc_open</i> method
has a host+port matchine one of the prefixes in the rc file, then
If the url request from, say, the <i>netcdf_open</i> method
has a host+port matching one of the prefixes in the rc file, then
the corresponding entry will be used, otherwise ignored.
<p>
For example, the URL
@ -230,7 +252,7 @@ http://fake.ucar.edu:9090/dts/test.01
</pre>
will have HTTP.VERBOSE set to 0.
<h2 class="break"><a name="CLIENTCERTS"><u>Client-Side Certificates</u></a></h2>
<h2><a name="CLIENTCERTS">Client-Side Certificates</a></h2>
Some systems, notably ESG (Earth System Grid), requires
the use of client-side certificates, as well as being
<a href="#REDIR">re-direction based</a>.
@ -245,8 +267,10 @@ This requires setting the following entries:
</ul>
Note that the first two are to support re-direction based authentication.
<h5 class="break"><a name="allkeys"><u>Appendix A. All RC-File Keys</u></a></h5>
<h1 class="appendix><a name="allkeys">Appendix A. All RC-File Keys</a></h1>
For completeness, this is the list of all rc-file keys.
If this documentation is out of date with respect to the actual code,
the code is definitive.
<table>
<tr><th>Key<th>curl_easy_setopt Option
<tr valign="top"><td>HTTP.DEFLATE<td>CUROPT_DEFLATE<br>with value "deflate,gzip"
@ -267,14 +291,23 @@ For completeness, this is the list of all rc-file keys.
</table>
</ul>
<h5 class="break"><a name="ESGDETAIL"><u>Appendix B. ESG Access in Detail</u></a></h5>
<h1 class="appendix"><a name="URSDETAIL">Appendix B. URS Access in Detail</a></h1>
It is possible to use the NASA Earthdata Login System (URS)
with netcdf by using using the process specified in the
<a href="#REDIR">redirection</a> based authorization section.
In order to access URS controlled datasets, however, it is necessary to
register as a user with NASA at the
<i>https://uat.urs.earthdata.nasa.gov/</i>
website.
<h1 class="appendix"><a name="ESGDETAIL">Appendix C. ESG Access in Detail</a></h1>
It is possible to access Earth Systems Grid (ESG) datasets
from ESG servers through the OC API using the techniques
from ESG servers through the netCDF API using the techniques
described in the section on <a href="#CLIENTCERTS">Client-Side Certificates</a>.
<p>
In order to access ESG datasets, however, it is necessary to
register as a user with ESG and to setup your environment
so that proper authentication is established between an oc
so that proper authentication is established between an netcdf
client program and the ESG data server. Specifically, it
is necessary to use what is called "client-side keys" to
enable this authentication. Normally, when a client accesses
@ -284,10 +317,10 @@ With client-side keys, the client must also provide a
certificate to the server so that the server can know with
whom it is communicating.
<p>
The oc library uses the <i>curl</i> library and it is that
The netcdf library uses the <i>curl</i> library and it is that
underlying library that must be properly configured.
<h3><u>Terminology</u></h3>
<h3>Terminology</h3>
The key elements for client-side keys requires the constructions of
two "stores" on the client side.
<ul>
@ -299,7 +332,7 @@ two "stores" on the client side.
The server actually has a similar set of stores, but the client
need not be concerned with those.
<h3><u>Initial Steps</u></h3>
<h3>Initial Steps</h3>
The first step is to obtain authorization from ESG.
Note that this information may evolve over time, and
@ -327,7 +360,7 @@ to substitute as necessary.
(read the whole page, it will help you understand the remaining steps).
</ol>
<h3><u>Building the KeyStore</u></h3>
<h3>Building the KeyStore</h3>
You will have to modify the keyfile in the previous step
and then create a keystore and install the key and a certificate.
The commands are these:
@ -341,7 +374,7 @@ The commands are these:
Note, the file names "key.der" and "cert.der" can be whatever you choose.
It is probably best to leave the .der extension, though.
<h3><u>Building the TrustStore</u></h3>
<h3>Building the TrustStore</h3>
Building the truststore is a bit tricky because as provided, the
certificates in ".globus" need some massaging. See the script below
for the details. The primary command is this, which is executed for every
@ -351,7 +384,7 @@ named "truststore"
keytool -trustcacerts -storepass "password" -v -keystore "truststore" -importcert -file "${c}"
</pre>
<h3><u>Running the C Client</u></h3>
<h3>Running the C Client</h3>
Refer to the section on <a href="#CLIENTCERTS">Client-Side Certificates</a>.
The keys specified there must be set in the rc file to support
@ -378,7 +411,7 @@ redirects to a separate authentication server. When that
server has authenticated the client, it redirects back to
the original url to complete the request.
<h3><u>Script for creating Stores</u></h3>
<h3>Script for creating Stores</h3>
The following script shows in detail how to actually construct the key
and trust stores. It is specific to the format of the globus file
as it was when ESG support was first added. It may have changed

489
docs/auth.md
View File

@ -1,489 +0,0 @@
Authorization Support in the netCDF-C Libraries {#oc_auth}
==================================================
\brief It is possible to support a number of authorization schemes
in the netCDF-C library.
With one exception, authorization in the netCDF-C library is
delegated to the oc2 code, which in turn delegates it to the
libcurl library. The exception is that the location of the rc
file can be specified by setting the environment variable *NCRCFILE*.
Note that the value of this environment variable should be the
absolute path of the rc file, not the path to its containing directory.
Following is the authorization documentation.
<center>
OC Authorization Support {#oc_auth_support}
========================
Author: Dennis Heimbigner<br>
dmh at ucar dot edu
Draft: 11/21/2014<br>
Last Revised: 12/23/2014<br>
OC Version 2.1
</center>
## Table of Contents {#auth_toc}
1. [Introduction](#Introduction)
2. [URL-Based Authentication](#URL-AUTH)
3. [RC File Authentication](#DODSRC)
4. [Redirection-Based Authentication](#REDIR)
5. [URL Constrained RC File Entries](#URLCONS)
6. [Client-Side Certificates](#CLIENTCERTS)
7. [Appendix A. All RC-File Keys](#allkeys)
8. [Appendix B. ESG Access in Detail](#ESGDETAIL)
## Introduction {#Introduction}
OC can support user authorization using those provided by the curl
library. This includes basic password authentication as well as
certificate-based authorization.
With some exceptions (e.g. see the section on [redirection](#REDIR)) The
libcurl authorization mechanisms can be accessed in two ways
1. Inserting the username and password into the url, or
2. Accessing information from a so-called *rc* file named either
*.daprc* or *.dodsrc*
## URL-Based Authentication {#URL-AUTH}
For simple password based authentication, it is possible to directly
insert the username and the password into a url in this form.
http://username:password@host/...
This username and password will be used if the server asks for
authentication. Note that only simple password authentication is
supported in this format. Specifically note that [redirection](#REDIR)
based authorization will not work with this.
## RC File Authentication {#DODSRC}
The oc library supports an *rc* file mechanism to allow the passing of a
number of parameters to liboc and libcurl.
The file must be called one of the following names: ".daprc", ".dodsrc"
If both .daprc and .dodsrc exist, then the .daprc file will take
precedence.
Searching for the rc file first looks in the current directory and then
in the home directory (as defined by the HOME environment variable). It
is also possible to specify a direct path using the *-R* option to
ocprint or using the *oc\_set\_rcfile* procedure (see oc.h). Note that
for these latter cases, the path must be to the file itself, not to the
containing directory.
The rc file format is a series of lines of the general form:
[<host:port>]<key>=<value>
where the bracket-enclosed host:port is optional and will be discussed
subsequently.
The currently defined set of authorization-related keys are as follows.
The second column is the affected curl\_easy\_setopt option(s).
Key
curl\_easy\_setopt Option
HTTP.COOKIEJAR
CURLOPT\_COOKIEJAR, CURLOPT\_COOKIEFILE
HTTP.PROXY\_SERVER
CURLOPT\_PROXY, CURLOPT\_PROXYPORT, CURLOPT\_PROXYUSERPWD
HTTP.SSL.CERTIFICATE
CURLOPT\_SSLCERT
HTTP.SSL.KEY
CURLOPT\_SSLKEY
HTTP.SSL.KEYPASSWORD
CURLOPT\_KEYPASSWORD
HTTP.SSL.CAINFO
CURLOPT\_SSLCAINFO
HTTP.SSL.CAPATH
CURLOPT\_SSLCAPATH
HTTP.SSL.VERIFYPEER
CURLOPT\_SSL\_VERIFYPEER
HTTP.CREDENTIALS.USERPASSWORD
CURLOPT\_USERPASSWORD
### Password Authentication
The key HTTP.CREDENTIALS.USERPASSWORD can be used to set the simple
password authentication. This is an alternative to setting it in the
url. The value must be of the form "username:password".
### Cookie Jar
The HTTP.COOKIEJAR key specifies the name of file from which to read
cookies (CURLOPT\_COOKIEJAR) and also the file into which to store
cookies (CURLOPT\_COOKIEFILE). The same value is used for both CURLOPT
values. It defaults to in-memory storage.
### Certificate Authentication
HTTP.SSL.CERTIFICATE specifies a file path for a file containing a PEM
cerficate. This is typically used for client-side authentication.
HTTP.SSL.KEY is essentially the same as HTTP.SSL.CERTIFICATE and should
usually have the same value.
HTTP.SSL.KEYPASSWORD specifies the password for accessing the
HTTP.SSL.KEY/HTTP.SSL.CERTIFICATE file.
HTTP.SSL.CAPATH specifies the path to a directory containing trusted
certificates for validating server sertificates.
HTTP.SSL.VALIDATE is a boolean (1/0) value that if true (1) specifies
that the client should verify the server's presented certificate.
HTTP.PROXY\_SERVER specified the url for accessing the proxy:
(e.g.http://\[username:password@\]host\[:port\])
## Redirection-Based Authentication {#REDIR}
Some sites provide authentication by using a third party site to to the
authentication. One example is
[URS](https://uat.urs.earthdata.nasa.gov), the EOSDIS User Registration
System.
The process is usually as follows.
1. The client contacts the server of interest (SOI), the actual
data provider.
2. The SOI sends a redirect to the client to connect to the URS system.
3. The client authenticates with URS.
4. URS sends a redirect (with authorization information) to send the
client back to the SOI to actually obtain the data.
In order for this to work with libcurl, the client will usually need to
provide a .netrc file so that the redirection will work correctly. The
format of this .netrc file will contain content that typically look like
this.
machine uat.urs.earthdata.nasa.gov login xxxxxx password yyyyyy
where the machine is the one to which the client is redirected for
authorization, and the login and password are those needed to
authenticate.
The .netrc file can be specified in two ways.
1. Specify the netrc file to liboc using the procedure in oc.h:
oc_set_netrc(OClink* link, const char* file)
(This is equivalent to the -N flag to ocprint).
2. Put the following line in your .daprc/.dodsrc file.
HTTP.NETRC=<path to netrc file>
One final note. In using this, it is probable that you will need to
specify a cookie jar (HTTP.COOKIEJAR) so that the redirect site can pass
back authorization information.
## URL Constrained RC File Entries {#URLCONS}
Each line of the rc file can begin with a host+port enclosed in square
brackets. The form is "host:port". If the port is not specified then the
form is just "host". The reason that more of the url is not used is that
libcurl's authorization grain is not any finer than host level.
Examples.
[remotetest.unidata.ucar.edu]HTTP.VERBOSE=1
or
[fake.ucar.edu:9090]HTTP.VERBOSE=0
If the url request from, say, the *oc\_open* method has a host+port
matchine one of the prefixes in the rc file, then the corresponding
entry will be used, otherwise ignored.
For example, the URL
http://remotetest.unidata.ucar.edu/thredds/dodsC/testdata/testData.nc
will have HTTP.VERBOSE set to 1.
Similarly,
http://fake.ucar.edu:9090/dts/test.01
will have HTTP.VERBOSE set to 0.
## Client-Side Certificates {#CLIENTCERTS}
Some systems, notably ESG (Earth System Grid), requires the use of
client-side certificates, as well as being [re-direction based](#REDIR).
This requires setting the following entries:
- HTTP.COOKIEJAR — a file path for storing cookies
across re-direction.
- HTTP.NETRC — the path to the netrc file.
- HTTP.SSL.CERTIFICATE — the file path for the client side
certificate file.
- HTTP.SSL.KEY — this should have the same value
as HTTP.SSL.CERTIFICATE.
- HTTP.SSL.CAPATH — the path to a "certificates" directory.
- HTTP.SSL.VALIDATE — force validation of the server certificate.
Note that the first two are to support re-direction based
authentication.
## Appendix A. All RC-File Keys {#allkeys}
For completeness, this is the list of all rc-file keys.
Key
curl\_easy\_setopt Option
HTTP.DEFLATE
CUROPT\_DEFLATE\
with value "deflate,gzip"
HTTP.VERBOSE
CUROPT\_VERBOSE
HTTP.TIMEOUT
CUROPT\_TIMEOUT
HTTP.USERAGENT
CUROPT\_USERAGENT
HTTP.COOKIEJAR
CUROPT\_COOKIEJAR
HTTP.COOKIE\_JAR
CUROPT\_COOKIEJAR
HTTP.PROXY\_SERVER
CURLOPT\_PROXY,\
CURLOPT\_PROXYPORT,\
CURLOPT\_PROXYUSERPWD
HTTP.SSL.CERTIFICATE
CUROPT\_SSLCERT
HTTP.SSL.KEY
CUROPT\_SSLKEY
HTTP.SSL.KEYPASSWORD
CUROPT\_KEYPASSWORD
HTTP.SSL.CAINFO
CUROPT\_SSLCAINFO
HTTP.SSL.CAPATH
CUROPT\_SSLCAPATH
HTTP.SSL.VERIFYPEER
CUROPT\_SSL\_VERIFYPEER
HTTP.CREDENTIALS.USERPASSWORD
CUROPT\_USERPASSWORD
HTTP.NETRC
CURLOPT\_NETRC,CURLOPT\_NETRC\_FILE
## Appendix B. ESG Access in Detail {#ESGDETAIL}
It is possible to access Earth Systems Grid (ESG) datasets from ESG
servers through the OC API using the techniques described in the section
on [Client-Side Certificates](#CLIENTCERTS).
In order to access ESG datasets, however, it is necessary to register as
a user with ESG and to setup your environment so that proper
authentication is established between an oc client program and the ESG
data server. Specifically, it is necessary to use what is called
"client-side keys" to enable this authentication. Normally, when a
client accesses a server in a secure fashion (using "https"), the server
provides an authentication certificate to the client. With client-side
keys, the client must also provide a certificate to the server so that
the server can know with whom it is communicating.
The oc library uses the *curl* library and it is that underlying library
that must be properly configured.
### Terminology
The key elements for client-side keys requires the constructions of two
"stores" on the client side.
- Keystore - a repository to hold the client side key.
- Truststore - a repository to hold a chain of certificates that can
be used to validate the certificate sent by the server to
the client.
The server actually has a similar set of stores, but the client need not
be concerned with those.
### Initial Steps
The first step is to obtain authorization from ESG. Note that this
information may evolve over time, and may be out of date. This
discussion is in terms of BADC and NCSA. You will need to substitute as
necessary.
1. Register at http://badc.nerc.ac.uk/register to obtain access to badc
and to obtain an openid, which will looks something like:
https://ceda.ac.uk/openid/Firstname.Lastname
2. Ask BADC for access to whatever datasets are of interest.
3. Obtain short term credentials at
http://grid.ncsa.illinois.edu/myproxy/MyProxyLogon/ You will need to
download and run the MyProxyLogon program. This will create a
keyfile in, typically, the directory ".globus". The keyfile will
have a name similar to this: "x509up\_u13615" The other elements in
".globus" are certificates to use in validating the certificate your
client gets from the server.
4. Obtain the program source ImportKey.java from this location:
http://www.agentbob.info/agentbob/79-AB.html (read the whole page,
it will help you understand the remaining steps).
### Building the KeyStore
You will have to modify the keyfile in the previous step and then create
a keystore and install the key and a certificate. The commands are
these:
openssl pkcs8 -topk8 -nocrypt -in x509up_u13615 -inform PEM -out key.der -outform DER
openssl x509 -in x509up_u13615 -inform PEM -out cert.der -outform DER
java -classpath -Dkeypassword="" -Dkeystore=./ key.der cert.der
Note, the file names "key.der" and "cert.der" can be whatever you
choose. It is probably best to leave the .der extension, though.
### Building the TrustStore
Building the truststore is a bit tricky because as provided, the
certificates in ".globus" need some massaging. See the script below for
the details. The primary command is this, which is executed for every
certificate, c, in globus. It sticks the certificate into the file named
"truststore"
keytool -trustcacerts -storepass "password" -v -keystore "truststore" -importcert -file "${c}"
### Running the C Client
Refer to the section on [Client-Side Certificates](#CLIENTCERTS). The
keys specified there must be set in the rc file to support ESG access.
- HTTP.COOKIEJAR=\~/.dods\_cookies
- HTTP.NETRC=\~/.netrc
- HTTP.SSL.CERTIFICATE=\~/esgkeystore
- HTTP.SSL.KEY=\~/esgkeystore
- HTTP.SSL.CAPATH=\~/.globus
- HTTP.SSL.VALIDATE=1
Of course, the file paths above are suggestions only; you can modify as
needed. The HTTP.SSL.CERTIFICATE and HTTP.SSL.KEY entries should have
same value, which is the file path for the certificate produced by
MyProxyLogon. The HTTP.SSL.CAPATH entry should be the path to the
"certificates" directory produced by MyProxyLogon.
As noted, also uses re-direction based authentication. So, when it
receives an initial connection from a client, it redirects to a separate
authentication server. When that server has authenticated the client, it
redirects back to the original url to complete the request.
### Script for creating Stores
The following script shows in detail how to actually construct the key
and trust stores. It is specific to the format of the globus file as it
was when ESG support was first added. It may have changed since then, in
which case, you will need to seek some help in fixing this script. It
would help if you communicated what you changed to the author so this
document can be updated.
#!/bin/sh -x
KEYSTORE="esgkeystore"
TRUSTSTORE="esgtruststore"
GLOBUS="globus"
TRUSTROOT="certificates"
CERT="x509up_u13615"
TRUSTROOTPATH="$GLOBUS/$TRUSTROOT"
CERTFILE="$GLOBUS/$CERT"
PWD="password"
D="-Dglobus=$GLOBUS"
CCP="bcprov-jdk16-145.jar"
CP="./build:${CCP}"
JAR="myproxy.jar"
# Initialize needed directories
rm -fr build
mkdir build
rm -fr $GLOBUS
mkdir $GLOBUS
rm -f $KEYSTORE
rm -f $TRUSTSTORE
# Compile MyProxyCmd and ImportKey
javac -d ./build -classpath "$CCP" *.java
javac -d ./build ImportKey.java
# Execute MyProxyCmd
java -cp "$CP myproxy.MyProxyCmd
# Build the keystore
openssl pkcs8 -topk8 -nocrypt -in $CERTFILE -inform PEM -out key.der -outform DER
openssl x509 -in $CERTFILE -inform PEM -out cert.der -outform DER
java -Dkeypassword=$PWD -Dkeystore=./${KEYSTORE} -cp ./build ImportKey key.der cert.der
# Clean up the certificates in the globus directory
for c in ${TRUSTROOTPATH}/*.0 ; do
alias=`basename $c .0`
sed -e '0,/---/d' <$c >/tmp/${alias}
echo "-----BEGIN CERTIFICATE-----" >$c
cat /tmp/${alias} >>$c
done
# Build the truststore
for c in ${TRUSTROOTPATH}/*.0 ; do
alias=`basename $c .0`
echo "adding: $TRUSTROOTPATH/${c}"
echo "alias: $alias"
yes | keytool -trustcacerts -storepass "$PWD" -v -keystore ./$TRUSTSTORE -alias $alias -importcert -file "${c}"
done
exit

14
docs/auth.md.in
View File

@ -1,14 +0,0 @@
Authorization Support in the netCDF-C Libraries {#oc_auth}
==================================================
\brief It is possible to support a number of authorization schemes
in the netCDF-C library.
With one exception, authorization in the netCDF-C library is
delegated to the oc2 code, which in turn delegates it to the
libcurl library. The exception is that the location of the rc
file can be specified by setting the environment variable *NCRCFILE*.
Note that the value of this environment variable should be the
absolute path of the rc file, not the path to its containing directory.
Following is the authorization documentation.

1
docs/esg.html
View File

@ -1,3 +1,4 @@
<!-- obsolete -->
<html><!-- InstanceBegin template="/Templates/MyUnidata.dwt" codeOutsideHTMLIsLocked="true" -->
<!-- This document is kept in netcdf-c/docs;
it is not normally included in the distribution.

475
docs/ocauth.md
View File

@ -1,475 +0,0 @@
<center>
OC Authorization Support {#oc_auth_support}
========================
Author: Dennis Heimbigner<br>
dmh at ucar dot edu
Draft: 11/21/2014<br>
Last Revised: 12/23/2014<br>
OC Version 2.1
</center>
## Table of Contents {#auth_toc}
1. [Introduction](#Introduction)
2. [URL-Based Authentication](#URL-AUTH)
3. [RC File Authentication](#DODSRC)
4. [Redirection-Based Authentication](#REDIR)
5. [URL Constrained RC File Entries](#URLCONS)
6. [Client-Side Certificates](#CLIENTCERTS)
7. [Appendix A. All RC-File Keys](#allkeys)
8. [Appendix B. ESG Access in Detail](#ESGDETAIL)
## Introduction {#Introduction}
OC can support user authorization using those provided by the curl
library. This includes basic password authentication as well as
certificate-based authorization.
With some exceptions (e.g. see the section on [redirection](#REDIR)) The
libcurl authorization mechanisms can be accessed in two ways
1. Inserting the username and password into the url, or
2. Accessing information from a so-called *rc* file named either
*.daprc* or *.dodsrc*
## URL-Based Authentication {#URL-AUTH}
For simple password based authentication, it is possible to directly
insert the username and the password into a url in this form.
http://username:password@host/...
This username and password will be used if the server asks for
authentication. Note that only simple password authentication is
supported in this format. Specifically note that [redirection](#REDIR)
based authorization will not work with this.
## RC File Authentication {#DODSRC}
The oc library supports an *rc* file mechanism to allow the passing of a
number of parameters to liboc and libcurl.
The file must be called one of the following names: ".daprc", ".dodsrc"
If both .daprc and .dodsrc exist, then the .daprc file will take
precedence.
Searching for the rc file first looks in the current directory and then
in the home directory (as defined by the HOME environment variable). It
is also possible to specify a direct path using the *-R* option to
ocprint or using the *oc\_set\_rcfile* procedure (see oc.h). Note that
for these latter cases, the path must be to the file itself, not to the
containing directory.
The rc file format is a series of lines of the general form:
[<host:port>]<key>=<value>
where the bracket-enclosed host:port is optional and will be discussed
subsequently.
The currently defined set of authorization-related keys are as follows.
The second column is the affected curl\_easy\_setopt option(s).
Key
curl\_easy\_setopt Option
HTTP.COOKIEJAR
CURLOPT\_COOKIEJAR, CURLOPT\_COOKIEFILE
HTTP.PROXY\_SERVER
CURLOPT\_PROXY, CURLOPT\_PROXYPORT, CURLOPT\_PROXYUSERPWD
HTTP.SSL.CERTIFICATE
CURLOPT\_SSLCERT
HTTP.SSL.KEY
CURLOPT\_SSLKEY
HTTP.SSL.KEYPASSWORD
CURLOPT\_KEYPASSWORD
HTTP.SSL.CAINFO
CURLOPT\_SSLCAINFO
HTTP.SSL.CAPATH
CURLOPT\_SSLCAPATH
HTTP.SSL.VERIFYPEER
CURLOPT\_SSL\_VERIFYPEER
HTTP.CREDENTIALS.USERPASSWORD
CURLOPT\_USERPASSWORD
### Password Authentication
The key HTTP.CREDENTIALS.USERPASSWORD can be used to set the simple
password authentication. This is an alternative to setting it in the
url. The value must be of the form "username:password".
### Cookie Jar
The HTTP.COOKIEJAR key specifies the name of file from which to read
cookies (CURLOPT\_COOKIEJAR) and also the file into which to store
cookies (CURLOPT\_COOKIEFILE). The same value is used for both CURLOPT
values. It defaults to in-memory storage.
### Certificate Authentication
HTTP.SSL.CERTIFICATE specifies a file path for a file containing a PEM
cerficate. This is typically used for client-side authentication.
HTTP.SSL.KEY is essentially the same as HTTP.SSL.CERTIFICATE and should
usually have the same value.
HTTP.SSL.KEYPASSWORD specifies the password for accessing the
HTTP.SSL.KEY/HTTP.SSL.CERTIFICATE file.
HTTP.SSL.CAPATH specifies the path to a directory containing trusted
certificates for validating server sertificates.
HTTP.SSL.VALIDATE is a boolean (1/0) value that if true (1) specifies
that the client should verify the server's presented certificate.
HTTP.PROXY\_SERVER specified the url for accessing the proxy:
(e.g.http://\[username:password@\]host\[:port\])
## Redirection-Based Authentication {#REDIR}
Some sites provide authentication by using a third party site to to the
authentication. One example is
[URS](https://uat.urs.earthdata.nasa.gov), the EOSDIS User Registration
System.
The process is usually as follows.
1. The client contacts the server of interest (SOI), the actual
data provider.
2. The SOI sends a redirect to the client to connect to the URS system.
3. The client authenticates with URS.
4. URS sends a redirect (with authorization information) to send the
client back to the SOI to actually obtain the data.
In order for this to work with libcurl, the client will usually need to
provide a .netrc file so that the redirection will work correctly. The
format of this .netrc file will contain content that typically look like
this.
machine uat.urs.earthdata.nasa.gov login xxxxxx password yyyyyy
where the machine is the one to which the client is redirected for
authorization, and the login and password are those needed to
authenticate.
The .netrc file can be specified in two ways.
1. Specify the netrc file to liboc using the procedure in oc.h:
oc_set_netrc(OClink* link, const char* file)
(This is equivalent to the -N flag to ocprint).
2. Put the following line in your .daprc/.dodsrc file.
HTTP.NETRC=<path to netrc file>
One final note. In using this, it is probable that you will need to
specify a cookie jar (HTTP.COOKIEJAR) so that the redirect site can pass
back authorization information.
## URL Constrained RC File Entries {#URLCONS}
Each line of the rc file can begin with a host+port enclosed in square
brackets. The form is "host:port". If the port is not specified then the
form is just "host". The reason that more of the url is not used is that
libcurl's authorization grain is not any finer than host level.
Examples.
[remotetest.unidata.ucar.edu]HTTP.VERBOSE=1
or
[fake.ucar.edu:9090]HTTP.VERBOSE=0
If the url request from, say, the *oc\_open* method has a host+port
matchine one of the prefixes in the rc file, then the corresponding
entry will be used, otherwise ignored.
For example, the URL
http://remotetest.unidata.ucar.edu/thredds/dodsC/testdata/testData.nc
will have HTTP.VERBOSE set to 1.
Similarly,
http://fake.ucar.edu:9090/dts/test.01
will have HTTP.VERBOSE set to 0.
## Client-Side Certificates {#CLIENTCERTS}
Some systems, notably ESG (Earth System Grid), requires the use of
client-side certificates, as well as being [re-direction based](#REDIR).
This requires setting the following entries:
- HTTP.COOKIEJAR — a file path for storing cookies
across re-direction.
- HTTP.NETRC — the path to the netrc file.
- HTTP.SSL.CERTIFICATE — the file path for the client side
certificate file.
- HTTP.SSL.KEY — this should have the same value
as HTTP.SSL.CERTIFICATE.
- HTTP.SSL.CAPATH — the path to a "certificates" directory.
- HTTP.SSL.VALIDATE — force validation of the server certificate.
Note that the first two are to support re-direction based
authentication.
## Appendix A. All RC-File Keys {#allkeys}
For completeness, this is the list of all rc-file keys.
Key
curl\_easy\_setopt Option
HTTP.DEFLATE
CUROPT\_DEFLATE\
with value "deflate,gzip"
HTTP.VERBOSE
CUROPT\_VERBOSE
HTTP.TIMEOUT
CUROPT\_TIMEOUT
HTTP.USERAGENT
CUROPT\_USERAGENT
HTTP.COOKIEJAR
CUROPT\_COOKIEJAR
HTTP.COOKIE\_JAR
CUROPT\_COOKIEJAR
HTTP.PROXY\_SERVER
CURLOPT\_PROXY,\
CURLOPT\_PROXYPORT,\
CURLOPT\_PROXYUSERPWD
HTTP.SSL.CERTIFICATE
CUROPT\_SSLCERT
HTTP.SSL.KEY
CUROPT\_SSLKEY
HTTP.SSL.KEYPASSWORD
CUROPT\_KEYPASSWORD
HTTP.SSL.CAINFO
CUROPT\_SSLCAINFO
HTTP.SSL.CAPATH
CUROPT\_SSLCAPATH
HTTP.SSL.VERIFYPEER
CUROPT\_SSL\_VERIFYPEER
HTTP.CREDENTIALS.USERPASSWORD
CUROPT\_USERPASSWORD
HTTP.NETRC
CURLOPT\_NETRC,CURLOPT\_NETRC\_FILE
## Appendix B. ESG Access in Detail {#ESGDETAIL}
It is possible to access Earth Systems Grid (ESG) datasets from ESG
servers through the OC API using the techniques described in the section
on [Client-Side Certificates](#CLIENTCERTS).
In order to access ESG datasets, however, it is necessary to register as
a user with ESG and to setup your environment so that proper
authentication is established between an oc client program and the ESG
data server. Specifically, it is necessary to use what is called
"client-side keys" to enable this authentication. Normally, when a
client accesses a server in a secure fashion (using "https"), the server
provides an authentication certificate to the client. With client-side
keys, the client must also provide a certificate to the server so that
the server can know with whom it is communicating.
The oc library uses the *curl* library and it is that underlying library
that must be properly configured.
### Terminology
The key elements for client-side keys requires the constructions of two
"stores" on the client side.
- Keystore - a repository to hold the client side key.
- Truststore - a repository to hold a chain of certificates that can
be used to validate the certificate sent by the server to
the client.
The server actually has a similar set of stores, but the client need not
be concerned with those.
### Initial Steps
The first step is to obtain authorization from ESG. Note that this
information may evolve over time, and may be out of date. This
discussion is in terms of BADC and NCSA. You will need to substitute as
necessary.
1. Register at http://badc.nerc.ac.uk/register to obtain access to badc
and to obtain an openid, which will looks something like:
https://ceda.ac.uk/openid/Firstname.Lastname
2. Ask BADC for access to whatever datasets are of interest.
3. Obtain short term credentials at
http://grid.ncsa.illinois.edu/myproxy/MyProxyLogon/ You will need to
download and run the MyProxyLogon program. This will create a
keyfile in, typically, the directory ".globus". The keyfile will
have a name similar to this: "x509up\_u13615" The other elements in
".globus" are certificates to use in validating the certificate your
client gets from the server.
4. Obtain the program source ImportKey.java from this location:
http://www.agentbob.info/agentbob/79-AB.html (read the whole page,
it will help you understand the remaining steps).
### Building the KeyStore
You will have to modify the keyfile in the previous step and then create
a keystore and install the key and a certificate. The commands are
these:
openssl pkcs8 -topk8 -nocrypt -in x509up_u13615 -inform PEM -out key.der -outform DER
openssl x509 -in x509up_u13615 -inform PEM -out cert.der -outform DER
java -classpath -Dkeypassword="" -Dkeystore=./ key.der cert.der
Note, the file names "key.der" and "cert.der" can be whatever you
choose. It is probably best to leave the .der extension, though.
### Building the TrustStore
Building the truststore is a bit tricky because as provided, the
certificates in ".globus" need some massaging. See the script below for
the details. The primary command is this, which is executed for every
certificate, c, in globus. It sticks the certificate into the file named
"truststore"
keytool -trustcacerts -storepass "password" -v -keystore "truststore" -importcert -file "${c}"
### Running the C Client
Refer to the section on [Client-Side Certificates](#CLIENTCERTS). The
keys specified there must be set in the rc file to support ESG access.
- HTTP.COOKIEJAR=\~/.dods\_cookies
- HTTP.NETRC=\~/.netrc
- HTTP.SSL.CERTIFICATE=\~/esgkeystore
- HTTP.SSL.KEY=\~/esgkeystore
- HTTP.SSL.CAPATH=\~/.globus
- HTTP.SSL.VALIDATE=1
Of course, the file paths above are suggestions only; you can modify as
needed. The HTTP.SSL.CERTIFICATE and HTTP.SSL.KEY entries should have
same value, which is the file path for the certificate produced by
MyProxyLogon. The HTTP.SSL.CAPATH entry should be the path to the
"certificates" directory produced by MyProxyLogon.
As noted, also uses re-direction based authentication. So, when it
receives an initial connection from a client, it redirects to a separate
authentication server. When that server has authenticated the client, it
redirects back to the original url to complete the request.
### Script for creating Stores
The following script shows in detail how to actually construct the key
and trust stores. It is specific to the format of the globus file as it
was when ESG support was first added. It may have changed since then, in
which case, you will need to seek some help in fixing this script. It
would help if you communicated what you changed to the author so this
document can be updated.
#!/bin/sh -x
KEYSTORE="esgkeystore"
TRUSTSTORE="esgtruststore"
GLOBUS="globus"
TRUSTROOT="certificates"
CERT="x509up_u13615"
TRUSTROOTPATH="$GLOBUS/$TRUSTROOT"
CERTFILE="$GLOBUS/$CERT"
PWD="password"
D="-Dglobus=$GLOBUS"
CCP="bcprov-jdk16-145.jar"
CP="./build:${CCP}"
JAR="myproxy.jar"
# Initialize needed directories
rm -fr build
mkdir build
rm -fr $GLOBUS
mkdir $GLOBUS
rm -f $KEYSTORE
rm -f $TRUSTSTORE
# Compile MyProxyCmd and ImportKey
javac -d ./build -classpath "$CCP" *.java
javac -d ./build ImportKey.java
# Execute MyProxyCmd
java -cp "$CP myproxy.MyProxyCmd
# Build the keystore
openssl pkcs8 -topk8 -nocrypt -in $CERTFILE -inform PEM -out key.der -outform DER
openssl x509 -in $CERTFILE -inform PEM -out cert.der -outform DER
java -Dkeypassword=$PWD -Dkeystore=./${KEYSTORE} -cp ./build ImportKey key.der cert.der
# Clean up the certificates in the globus directory
for c in ${TRUSTROOTPATH}/*.0 ; do
alias=`basename $c .0`
sed -e '0,/---/d' <$c >/tmp/${alias}
echo "-----BEGIN CERTIFICATE-----" >$c
cat /tmp/${alias} >>$c
done
# Build the truststore
for c in ${TRUSTROOTPATH}/*.0 ; do
alias=`basename $c .0`
echo "adding: $TRUSTROOTPATH/${c}"
echo "alias: $alias"
yes | keytool -trustcacerts -storepass "$PWD" -v -keystore ./$TRUSTSTORE -alias $alias -importcert -file "${c}"
done
exit

11
libdispatch/dfile.c
View File

@ -1797,13 +1797,10 @@ NC_open(const char *path, int cmode,
else if(model & NC_DISPATCH_NC3) {
cmode &= ~NC_NETCDF4; /* must be netcdf-3 */
if(version == 2) cmode |= NC_64BIT_OFFSET;
} else if(model & NC_DISPATCH_NCP) {
#if 0
It appears that pnetcdf can read NC_64_BIT_OFFSET
cmode &= ~(NC_NETCDF4 | NC_64BIT_OFFSET); /* must be pnetcdf */
#else
cmode &= ~(NC_NETCDF4);
#endif
} else if(model & NC_DISPATCH_NCP) { /* pnetcdf */
/*It appears that pnetcdf can read NC_64_BIT_OFFSET*/
/* cmode &= ~(NC_NETCDF4 | NC_64BIT_OFFSET);*/ /* old code */
cmode &= ~(NC_NETCDF4); /* pnetcdf allows all NC_64BIT_OFFSET */
cmode |= NC_PNETCDF;
}

3
ncdump/Makefile.am
View File

@ -131,7 +131,8 @@ ref_tst_charfill.cdl tst_charfill.cdl tst_charfill.sh \
tst_iter.sh tst_mud.sh ref_tst_mud4.cdl ref_tst_mud4-bc.cdl \
ref_tst_mud4_chars.cdl \
ref_tst_ncf213.cdl tst_h_scalar.sh \
tst_formatx3.sh tst_formatx4.sh ref_tst_utf8_4.cdl \
run_utf8_nc4_tests.sh \
tst_formatx3.sh tst_formatx4.sh ref_tst_utf8_4.cdl \
CMakeLists.txt XGetopt.c tst_bom.sh tst_inmemory.sh
# CDL files and Expected results

2
oc2/Make0
View File

@ -25,7 +25,7 @@ ochttp.h ocread.h ocutil.h \
ocbytes.h oclist.h ocuri.h oclog.h \
xxdr.h
DOCS=docs/ocauth.html
DOCS=docs/auth.html.in docs/oc.css
MISC=dap.y

2
oc2/Makefile.am
View File

@ -31,7 +31,7 @@ ochttp.h ocread.h ocutil.h \
ocbytes.h oclist.h ocuri.h oclog.h \
xxdr.h
EXTRA_DIST = dap.y CMakeLists.txt ocauth.html
EXTRA_DIST = dap.y CMakeLists.txt auth.html.in oc.css
if BUILD_DAP
noinst_LTLIBRARIES = liboc.la

456
oc2/auth.html.in Normal file
View File

@ -0,0 +1,456 @@
<!- Copyright 2015, UCAR/Unidata and OPeNDAP, Inc. -->
<!- See the COPYRIGHT file for more information. -->
<html>
<head>
<link rel="stylesheet" type="text/css" href="oc.css">
</head>
<body>
<h1 class="title">ZZ Authorization Support</h1>
<div class="subtitle">
<h1>Author: Dennis Heimbigner</h1>
<h1>Address: http://www.unidata.ucar.edu/staff/dmh/</h1>
<h1>Draft: 11/21/2014</h1>
<h1>Last Revised: 10/24/2015</h1>
<OC><h1>ZZ Version 4.0</h1>
</div>
<h1 class="toc">Table of Contents</h1>
<ol>
<li> <a href="#Introduction">Introduction</a>
<li> <a href="#URL-AUTH">URL-Based Authentication</a>
<li> <a href="#DODSRC">RC File Authentication</a>
<li> <a href="#REDIR">Redirection-Based Authentication</a>
<li> <a href="#URLCONS">URL Constrained RC File Entries</a>
<li> <a href="#CLIENTCERTS">Client-Side Certificates</a>
<li> <a href="#allkeys">Appendix A. All RC-File Keys</a>
<li> <a href="#ESGDETAIL">Appendix B. ESG Access in Detail</a>
</ol>
<h2><a name="Introduction">Introduction</a></h2>
ZZ can support user authorization using the facilities provided by the curl
library. This includes basic password authentication as well as
certificate-based authorization.
<p>
With some exceptions (e.g. see the section on <a href="#REDIR">redirection</a>)
The libcurl authorization mechanisms can be accessed in two ways
<ol>
<li> Inserting the username and password into the url, or
<li> Accessing information from a so-called <i>rc</i> file named either
<i>.daprc</i> or <i>.dodsrc</i>
</ol>
<h2><a name="URL-AUTH">URL-Based Authentication</a></h2>
For simple password based authentication, it is possible to
directly insert the username and the password into a url in this form.
<pre>
http://username:password@host/...
</pre>
This username and password will be used if the server asks for
authentication. Note that only simple password authentication
is supported in this format.
Specifically note that <a href="#REDIR">redirection</a> based
authorization will not work with this because the username and password
will only be used on the initial request, not the redirection
<h2><a name="DODSRC">RC File Authentication</a></h2>
The zz library supports an <i>rc</i> file mechanism to allow the passing
of a number of parameters to libzz and libcurl.
<p>
The file must be called one of the following names:
".daprc" or ".dodsrc"
If both .daprc and .dodsrc exist, then
the .daprc file will take precedence.
<p>
The rc file is searched for first in the current directory
and then in the home directory (as defined by the HOME environment
variable).
<OC>It is also possible to specify a direct path using
<OC>the <i>-R</i> option to ocprint or using the <i>oc_set_rcfile</i>
<OC>procedure (see oc.h). Note that for these latter cases, the path
<OC>must be to the file itself, not to the containing directory.
<p>
The rc file format is a series of lines of the general form:
<pre>
[&lt;host:port&gt;]&lt;key&gt;=&lt;value&gt;
</pre>
where the bracket-enclosed host:port is optional and will be discussed
subsequently.
<p>
The currently defined set of authorization-related keys are as follows.
The second column is the affected curl_easy_setopt option(s), if any.
<table>
<tr><th>Key<th>Affected curl_easy_setopt Options<th>Notes
<tr><td>HTTP.COOKIEJAR<td>CURLOPT_COOKIEJAR
<tr><td>HTTP.COOKIEFILE<td>CURLOPT_COOKIEJAR<td>Alias for CURLOPT_COOKIEJAR
<tr><td>HTTP.PROXY_SERVER<td>CURLOPT_PROXY, CURLOPT_PROXYPORT, CURLOPT_PROXYUSERPWD
<tr><td>HTTP.SSL.CERTIFICATE<td>CURLOPT_SSLCERT
<tr><td>HTTP.SSL.KEY<td>CURLOPT_SSLKEY
<tr><td>HTTP.SSL.KEYPASSWORD<td>CURLOPT_KEYPASSWORD
<tr><td>HTTP.SSL.CAINFO<td>CURLOPT_SSLCAINFO
<tr><td>HTTP.SSL.CAPATH<td>CURLOPT_SSLCAPATH
<tr><td>HTTP.SSL.VERIFYPEER<td>CURLOPT_SSL_VERIFYPEER
<tr><td>HTTP.SSL.VALIDATE<td>CURLOPT_SSL_VERIFYPEER, CURLOPT_SSL_VERIFYHOST
<tr><td>HTTP.CREDENTIALS.USERPASSWORD<td>CURLOPT_USERPASSWORD
<tr><td>HTTP.NETRC<td>N.A.<td>Specify path of the .netrc file
</table>
</ul>
<h3>Password Authentication</h3>
The key
HTTP.CREDENTIALS.USERPASSWORD
can be used to set the simple password authentication.
This is an alternative to setting it in the url.
The value must be of the form "username:password".
See <a href="#REDIR">redirection authorization</a>
for important additional information.
<h3>Cookie Jar</h3>
The HTTP.COOKIEJAR key
specifies the name of file from which
to read cookies (CURLOPT_COOKIEJAR) and also
the file into which to store cookies (CURLOPT_COOKIEFILE).
The same value is used for both CURLOPT values.
It defaults to in-memory storage.
See <a href="#REDIR">redirection authorization</a>
for important additional information.
<h3>Certificate Authentication</h3>
HTTP.SSL.CERTIFICATE
specifies a file path for a file containing a PEM cerficate.
This is typically used for client-side authentication.
<p>
HTTP.SSL.KEY is essentially the same as HTTP.SSL.CERTIFICATE
and should always have the same value.
<p>
HTTP.SSL.KEYPASSWORD
specifies the password for accessing the HTTP.SSL.CERTIFICAT/HTTP.SSL.key file.
<p>
HTTP.SSL.CAPATH
specifies the path to a directory containing
trusted certificates for validating server sertificates.
<p>
HTTP.SSL.VALIDATE
is a boolean (1/0) value that if true (1)
specifies that the client should verify the server's presented certificate.
<p>
HTTP.PROXY_SERVER
specifies the url for accessing the proxy:
e.g. <i>http://[username:password@]host[:port]</i>
<p>
HTTP.NETRC
specifies the absolute path of the .netrc file.
See <a href="#REDIR">redirection authorization</a>
for information about using .netrc.
<h2><a name="REDIR">Redirection-Based Authentication</a> </h2>
Some sites provide authentication by using a third party site
to do the authentication. Examples include ESG and URS.
<p>
The process is usually as follows.
<ol>
<li>The client contacts the server of interest (SOI), the actual data provider
using, typically http protocol.
<li>The SOI sends a redirect to the client to connect to the e.g. URS system
using the 'https' protocol (note the use of https instead of http).
<li>The client authenticates with URS.
<li>URS sends a redirect (with authorization information) to send
the client back to the SOI to actually obtain the data.
</ol>
<p>
It turns out that libcurl uses the password in the .daprc file &mdash; or from the url &mdash;
only for the initial connection. This causes problems because
the redirected connection is the one that actually requires the password.
This is where .netrc comes in. Libcurl will use .netrc for
the redirected connection. It is possible to cause libcurl to use
the .daprc password always, but this introduces a security hole
because it may send the initial user+pwd to the redirection site.
In summary, if you are using redirection, then you must create a .netrc
file to hold the password for the site to which the redirection is sent.
<p>
The format of this .netrc file will contain content that
typically look like this.
<pre>
machine mmmmmm login xxxxxx password yyyyyy
</pre>
where the machine, mmmmmm, is the hostname of the machine to
which the client is redirected for authorization, and the
login and password are those needed to authenticate on that machine.
<p>
<NC>The .netrc file can be specified by
<NC>putting the following line in your .daprc/.dodsrc file.
<NC><pre>
<NC>HTTP.NETRC=&lt;path to netrc file&gt;
<NC></pre>
<OC>The .netrc file can be specified in two ways.
<OC><ol>
<OC><li> Specify the netrc file to libzz using the procedure in oc.h:
<OC><pre>
<OC>oc_set_netrc(OClink* link, const char* file)
<OC></pre>
<OC>(This is equivalent to the -N flag to ocprint).
<OC><p>
<OC><li> Put the following line in your .daprc/.dodsrc file.
<OC><pre>
<OC>HTTP.NETRC=&lt;path to netrc file&gt;
<OC></pre>
<OC></ol>
<p>
One final note. In using this, it is almost certain that you will
need to specify a real cookie jar file (HTTP.COOKIEJAR) so that the
redirect site can pass back authorization information.
<h2><a name="URLCONS">URL Constrained RC File Entries</a></h2>
Each line of the rc file can begin with
a host+port enclosed in square brackets.
The form is "host:port".
If the port is not specified
then the form is just "host".
The reason that more of the url is not used is that
libcurl's authorization grain is not any finer than host level.
<p>
Examples.
<pre>
[remotetest.unidata.ucar.edu]HTTP.VERBOSE=1
or
[fake.ucar.edu:9090]HTTP.VERBOSE=0
</pre>
If the url request from, say, the <i>zz_open</i> method
has a host+port matching one of the prefixes in the rc file, then
the corresponding entry will be used, otherwise ignored.
<p>
For example, the URL
<pre>
http://remotetest.unidata.ucar.edu/thredds/dodsC/testdata/testData.nc
</pre>
will have HTTP.VERBOSE set to 1.
<p>
Similarly,
<pre>
http://fake.ucar.edu:9090/dts/test.01
</pre>
will have HTTP.VERBOSE set to 0.
<h2><a name="CLIENTCERTS">Client-Side Certificates</a></h2>
Some systems, notably ESG (Earth System Grid), requires
the use of client-side certificates, as well as being
<a href="#REDIR">re-direction based</a>.
This requires setting the following entries:
<ul>
<li>HTTP.COOKIEJAR &mdash; a file path for storing cookies across re-direction.
<li>HTTP.NETRC &mdash; the path to the netrc file.
<li>HTTP.SSL.CERTIFICATE &mdash; the file path for the client side certificate file.
<li>HTTP.SSL.KEY &mdash; this should have the same value as HTTP.SSL.CERTIFICATE.
<li>HTTP.SSL.CAPATH &mdash; the path to a "certificates" directory.
<li>HTTP.SSL.VALIDATE &mdash; force validation of the server certificate.
</ul>
Note that the first two are to support re-direction based authentication.
<h1 class="appendix><a name="allkeys">Appendix A. All RC-File Keys</a></h1>
For completeness, this is the list of all rc-file keys.
If this documentation is out of date with respect to the actual code,
the code is definitive.
<table>
<tr><th>Key<th>curl_easy_setopt Option
<tr valign="top"><td>HTTP.DEFLATE<td>CUROPT_DEFLATE<br>with value "deflate,gzip"
<tr><td>HTTP.VERBOSE <td>CUROPT_VERBOSE
<tr><td>HTTP.TIMEOUT<td>CUROPT_TIMEOUT
<tr><td>HTTP.USERAGENT<td>CUROPT_USERAGENT
<tr><td>HTTP.COOKIEJAR<td>CUROPT_COOKIEJAR
<tr><td>HTTP.COOKIE_JAR<td>CUROPT_COOKIEJAR
<tr valign="top"><td>HTTP.PROXY_SERVER<td>CURLOPT_PROXY,<br>CURLOPT_PROXYPORT,<br>CURLOPT_PROXYUSERPWD
<tr><td>HTTP.SSL.CERTIFICATE<td>CUROPT_SSLCERT
<tr><td>HTTP.SSL.KEY<td>CUROPT_SSLKEY
<tr><td>HTTP.SSL.KEYPASSWORD<td>CUROPT_KEYPASSWORD
<tr><td>HTTP.SSL.CAINFO<td>CUROPT_SSLCAINFO
<tr><td>HTTP.SSL.CAPATH<td>CUROPT_SSLCAPATH
<tr><td>HTTP.SSL.VERIFYPEER<td>CUROPT_SSL_VERIFYPEER
<tr><td>HTTP.CREDENTIALS.USERPASSWORD<td>CUROPT_USERPASSWORD
<tr><td>HTTP.NETRC<td>CURLOPT_NETRC,CURLOPT_NETRC_FILE
</table>
</ul>
<h1 class="appendix"><a name="URSDETAIL">Appendix B. URS Access in Detail</a></h1>
It is possible to use the NASA Earthdata Login System (URS)
with zz by using using the process specified in the
<a href="#REDIR">redirection</a> based authorization section.
In order to access URS controlled datasets, however, it is necessary to
register as a user with NASA at the
<i>https://uat.urs.earthdata.nasa.gov/</i>
website.
<h1 class="appendix"><a name="ESGDETAIL">Appendix C. ESG Access in Detail</a></h1>
It is possible to access Earth Systems Grid (ESG) datasets
from ESG servers through the ZZ API using the techniques
described in the section on <a href="#CLIENTCERTS">Client-Side Certificates</a>.
<p>
In order to access ESG datasets, however, it is necessary to
register as a user with ESG and to setup your environment
so that proper authentication is established between an zz
client program and the ESG data server. Specifically, it
is necessary to use what is called "client-side keys" to
enable this authentication. Normally, when a client accesses
a server in a secure fashion (using "https"), the server
provides an authentication certificate to the client.
With client-side keys, the client must also provide a
certificate to the server so that the server can know with
whom it is communicating.
<p>
The zz library uses the <i>curl</i> library and it is that
underlying library that must be properly configured.
<h3>Terminology</h3>
The key elements for client-side keys requires the constructions of
two "stores" on the client side.
<ul>
<li> Keystore - a repository to hold the client side key.
<li> Truststore - a repository to hold a chain of certificates
that can be used to validate the certificate
sent by the server to the client.
</ul>
The server actually has a similar set of stores, but the client
need not be concerned with those.
<h3>Initial Steps</h3>
The first step is to obtain authorization from ESG.
Note that this information may evolve over time, and
may be out of date.
This discussion is in terms of BADC and NCSA. You will need
to substitute as necessary.
<ol>
<li> Register at http://badc.nerc.ac.uk/register
to obtain access to badc and to obtain an openid,
which will looks something like:
<pre>https://ceda.ac.uk/openid/Firstname.Lastname</pre>
<li> Ask BADC for access to whatever datasets are of interest.
<p>
<li> Obtain short term credentials at
http://grid.ncsa.illinois.edu/myproxy/MyProxyLogon/
You will need to download and run the MyProxyLogon
program.
This will create a keyfile in, typically, the directory ".globus".
The keyfile will have a name similar to this: "x509up_u13615"
The other elements in ".globus" are certificates to use in
validating the certificate your client gets from the server.
<p>
<li> Obtain the program source ImportKey.java
from this location: http://www.agentbob.info/agentbob/79-AB.html
(read the whole page, it will help you understand the remaining steps).
</ol>
<h3>Building the KeyStore</h3>
You will have to modify the keyfile in the previous step
and then create a keystore and install the key and a certificate.
The commands are these:
<pre>
openssl pkcs8 -topk8 -nocrypt -in x509up_u13615 -inform PEM -out key.der -outform DER
openssl x509 -in x509up_u13615 -inform PEM -out cert.der -outform DER
java -classpath <path to ImportKey.class> -Dkeypassword="<password>" -Dkeystore=./<keystorefilename> key.der cert.der
</pre>
Note, the file names "key.der" and "cert.der" can be whatever you choose.
It is probably best to leave the .der extension, though.
<h3>Building the TrustStore</h3>
Building the truststore is a bit tricky because as provided, the
certificates in ".globus" need some massaging. See the script below
for the details. The primary command is this, which is executed for every
certificate, c, in globus. It sticks the certificate into the file
named "truststore"
<pre>
keytool -trustcacerts -storepass "password" -v -keystore "truststore" -importcert -file "${c}"
</pre>
<h3>Running the C Client</h3>
Refer to the section on <a href="#CLIENTCERTS">Client-Side Certificates</a>.
The keys specified there must be set in the rc file to support
ESG access.
<ul>
<li> HTTP.COOKIEJAR=~/.dods_cookies
<li> HTTP.NETRC=~/.netrc
<li> HTTP.SSL.CERTIFICATE=~/esgkeystore
<li> HTTP.SSL.KEY=~/esgkeystore
<li> HTTP.SSL.CAPATH=~/.globus
<li> HTTP.SSL.VALIDATE=1
</ul>
Of course, the file paths above are suggestions only;
you can modify as needed.
The HTTP.SSL.CERTIFICATE and HTTP.SSL.KEY
entries should have same value, which is the file path for the
certificate produced by MyProxyLogon. The HTTP.SSL.CAPATH entry
should be the path to the "certificates" directory produced by
MyProxyLogon.
<p>
As noted, also uses re-direction based authentication.
So, when it receives an initial connection from a client, it
redirects to a separate authentication server. When that
server has authenticated the client, it redirects back to
the original url to complete the request.
<h3>Script for creating Stores</h3>
The following script shows in detail how to actually construct the key
and trust stores. It is specific to the format of the globus file
as it was when ESG support was first added. It may have changed
since then, in which case, you will need to seek some help
in fixing this script. It would help if you communicated
what you changed to the author so this document can be updated.
<pre>
#!/bin/sh -x
KEYSTORE="esgkeystore"
TRUSTSTORE="esgtruststore"
GLOBUS="globus"
TRUSTROOT="certificates"
CERT="x509up_u13615"
TRUSTROOTPATH="$GLOBUS/$TRUSTROOT"
CERTFILE="$GLOBUS/$CERT"
PWD="password"
D="-Dglobus=$GLOBUS"
CCP="bcprov-jdk16-145.jar"
CP="./build:${CCP}"
JAR="myproxy.jar"
# Initialize needed directories
rm -fr build
mkdir build
rm -fr $GLOBUS
mkdir $GLOBUS
rm -f $KEYSTORE
rm -f $TRUSTSTORE
# Compile MyProxyCmd and ImportKey
javac -d ./build -classpath "$CCP" *.java
javac -d ./build ImportKey.java
# Execute MyProxyCmd
java -cp "$CP myproxy.MyProxyCmd
# Build the keystore
openssl pkcs8 -topk8 -nocrypt -in $CERTFILE -inform PEM -out key.der -outform DER
openssl x509 -in $CERTFILE -inform PEM -out cert.der -outform DER
java -Dkeypassword=$PWD -Dkeystore=./${KEYSTORE} -cp ./build ImportKey key.der cert.der
# Clean up the certificates in the globus directory
for c in ${TRUSTROOTPATH}/*.0 ; do
alias=`basename $c .0`
sed -e '0,/---/d' <$c >/tmp/${alias}
echo "-----BEGIN CERTIFICATE-----" >$c
cat /tmp/${alias} >>$c
done
# Build the truststore
for c in ${TRUSTROOTPATH}/*.0 ; do
alias=`basename $c .0`
echo "adding: $TRUSTROOTPATH/${c}"
echo "alias: $alias"
yes | keytool -trustcacerts -storepass "$PWD" -v -keystore ./$TRUSTSTORE -alias $alias -importcert -file "${c}"
done
exit
</pre>
</body>
</html>

1634
oc2/daptab.c
View File

File diff suppressed because it is too large Load Diff

92
oc2/daptab.h
View File

@ -1,19 +1,19 @@
/* A Bison parser, made by GNU Bison 2.5. */
/* A Bison parser, made by GNU Bison 3.0. */
/* Bison interface for Yacc-like parsers in C
Copyright (C) 1984, 1989-1990, 2000-2011 Free Software Foundation, Inc.
Copyright (C) 1984, 1989-1990, 2000-2013 Free Software Foundation, Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
@ -26,54 +26,62 @@
special exception, which will cause the skeleton and the resulting
Bison output files to be licensed under the GNU General Public
License without this special exception.
This special exception was added by the Free Software Foundation in
version 2.2 of Bison. */
/* Tokens. */
#ifndef YYTOKENTYPE
# define YYTOKENTYPE
/* Put the tokens into the symbol table, so that GDB and other debuggers
know about them. */
enum yytokentype {
SCAN_ALIAS = 258,
SCAN_ARRAY = 259,
SCAN_ATTR = 260,
SCAN_BYTE = 261,
SCAN_CODE = 262,
SCAN_DATASET = 263,
SCAN_DATA = 264,
SCAN_ERROR = 265,
SCAN_FLOAT32 = 266,
SCAN_FLOAT64 = 267,
SCAN_GRID = 268,
SCAN_INT16 = 269,
SCAN_INT32 = 270,
SCAN_MAPS = 271,
SCAN_MESSAGE = 272,
SCAN_SEQUENCE = 273,
SCAN_STRING = 274,
SCAN_STRUCTURE = 275,
SCAN_UINT16 = 276,
SCAN_UINT32 = 277,
SCAN_URL = 278,
SCAN_PTYPE = 279,
SCAN_PROG = 280,
WORD_WORD = 281,
WORD_STRING = 282
};
#ifndef YY_DAP_DAP_TAB_H_INCLUDED
# define YY_DAP_DAP_TAB_H_INCLUDED
/* Debug traces. */
#ifndef YYDEBUG
# define YYDEBUG 1
#endif
#if YYDEBUG
extern int dapdebug;
#endif
/* Token type. */
#ifndef YYTOKENTYPE
# define YYTOKENTYPE
enum yytokentype
{
SCAN_ALIAS = 258,
SCAN_ARRAY = 259,
SCAN_ATTR = 260,
SCAN_BYTE = 261,
SCAN_CODE = 262,
SCAN_DATASET = 263,
SCAN_DATA = 264,
SCAN_ERROR = 265,
SCAN_FLOAT32 = 266,
SCAN_FLOAT64 = 267,
SCAN_GRID = 268,
SCAN_INT16 = 269,
SCAN_INT32 = 270,
SCAN_MAPS = 271,
SCAN_MESSAGE = 272,
SCAN_SEQUENCE = 273,
SCAN_STRING = 274,
SCAN_STRUCTURE = 275,
SCAN_UINT16 = 276,
SCAN_UINT32 = 277,
SCAN_URL = 278,
SCAN_PTYPE = 279,
SCAN_PROG = 280,
WORD_WORD = 281,
WORD_STRING = 282
};
#endif
/* Value type. */
#if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
typedef int YYSTYPE;
# define YYSTYPE_IS_TRIVIAL 1
# define yystype YYSTYPE /* obsolescent; will be withdrawn */
# define YYSTYPE_IS_DECLARED 1
#endif
int dapparse (DAPparsestate* parsestate);
#endif /* !YY_DAP_DAP_TAB_H_INCLUDED */

39
oc2/oc.css Normal file
View File

@ -0,0 +1,39 @@
<style>
.break { page-break-before: always; }
body { counter-reset: H2; font-size: 12pt; }
h1.title {
font-size: 18pt;
text-decoration: underline;
}
div.subtitle {
}
.subtitle h1 {
font-size: 14pt;
margin-top: 0;
margin-bottom: 0;
}
h1.toc {
font-size: 16pt;
text-decoration: underline;
}
h1.appendix {
font-size: 14pt;
}
h2:before {
content: counter(H2) " ";
counter-increment: H2;
}
h2 { counter-reset: H3; text-decoration: underline; }
h3:before {
content: counter(H2) "." counter(H3) " ";
counter-increment:H3;
}
h3 { counter-reset: H4; }
h4:before {
content: counter(H2) "." counter(H3) "." counter(H4) " ";
counter-increment:H4;
}
</style>