Quote all instances of the `service_proxy_auth` setting name.
[mkws-moved-to-github.git] / doc / library-configuration.markdown
index 530c4da..23b40ea 100644 (file)
@@ -27,7 +27,7 @@ the set of categories by which targets are classified for the library.
 Libraries are maintained using MKAdmin (MasterKey
 Admin). Specifically, those used by MKWS are generally maintained on
 the "MKC Admin" installation at
-       http://mkx-admin.indexdata.com/console/
+`http://mkx-admin.indexdata.com/console/`
 
 In general, Index Data will create a library for each customer, then
 give the customer a username/password pair that they can use to enter
@@ -66,32 +66,33 @@ unauthorised access.
 
 Setting up such a library is a process of several stages.
 
-Stage A: create the User Access account
+### Stage A: create the User Access account
 
 Log in to MKAdmin administrate your library:
-       - Go to http://mkc-admin.indexdata.com/console/
-       - Enter the adminstrative username/password
-       - Go to the User Access tab
-       - Create an end-user account
-       - Depending on what authentication method it be used, set the
-         User Access account's username and password, or IP-address
-         range, or referring URL, or hostname.
+
+* Go to `http://mkc-admin.indexdata.com/console/`
+* Enter the adminstrative username/password
+* Go to the User Access tab
+* Create an end-user account
+* Depending on what authentication method it be used, set the
+  User Access account's username and password, or IP-address range, or
+  referring URL, or hostname.
 
 If your MWKS application runs at a well-known, permanent address --
-http://yourname.com/app.html, say -- you can set the User Access
+`http://yourname.com/app.html`, say -- you can set the User Access
 record so that this originating URL is recognised by setting it into
 the "Referring URL" field.
 
 If your application accesses the Service Proxy by a unique virtual
 hostname -- yourname.sp-mkws.indexdata.com, say -- you can tie the use
 of this hostname to your library by setting the User Access record's
-"Host Name" field to name of the host where the SP is accessed. NOTE
-THAT THIS IS NOT SECURE, AS OTHER APPLICATIONS CAN USE THIS VIRTUAL
-HOSTNAME TO GAIN ACCESS TO YOUR LIBRARY.
+"Host Name" field to name of the host where the SP is accessed. **Note
+that this is not secure, as other applications can use this virtual
+hostname to gain access to your library.**
 
-### Authentication by IP address does not yet work correctly -- see
-bug MKWS-234 ("Improve SP configuration/proxying for better
-authentication").
+> TODO Authentication by IP address does not yet work correctly -- see
+> bug MKWS-234 ("Improve SP configuration/proxying for better
+> authentication").
 
 Alternatively, your application can authenticate by username and
 password credentials. This is a useful approach in several situations,
@@ -104,7 +105,7 @@ You can create multiple User Access records: for example, one that
 uses Referring URL, and another that uses a username/password pair to
 be used when running an application from a different URL.
 
-Stage B: tell the application to use the library
+### Stage B: tell the application to use the library
 
 In the HTML of the application, tell MKWS to authenticate on to the
 Service Proxy. When IP-based, referer-based or hostname-based
@@ -113,39 +114,39 @@ authentication is used, this is very simple:
        <script type="text/javascript">
          var mkws_config = { service_proxy_auth:
          "//sp-mkws.indexdata.com/service-proxy/?command=auth&action=perconfig" };
-        </script>
+       </script>
 
-### This should be the default setting
+> TODO This should be the default setting
 
 And ensure that access to the MWKS application is from the correct
 Referrer URL or IP-range.
 
-Stage C1 (optional): access by a different virtual hostname
+### Stage C1 (optional): access by a different virtual hostname
 
 When hostname-based authentication is in use, it's necessary to access
 the Service Proxy as the correctly named virtual host. This can be
-done by setting the service_proxy_auth configuration item to a
+done by setting the `service_proxy_auth` configuration item to a
 URL containing that hostname, such as
-       //yourname.sp-mkws.indexdata.com/service-proxy/?command=auth&action=perconfig
+`//yourname.sp-mkws.indexdata.com/service-proxy/?command=auth&action=perconfig`
 
-### It should be possible to change just the hostname without needing
-to repeat the rest of the URL (protocol, path, query)
+> TODO It should be possible to change just the hostname without
+> needing to repeat the rest of the URL (protocol, path, query)
 
-### When changing the SP authentication URL, the Pazpar2 URL should in
-general change along with it.
+> TODO When changing the SP authentication URL, the Pazpar2 URL should
+> in general change along with it.
 
-Stage C2 (optional): embed credentials for access to the library
+### Stage C2 (optional): embed credentials for access to the library
 
 When credential-based authentication is in use (username and
 password), it's necessary to pass these credentials into the Service
 Proxy when establishing the session. This can most simply be done just
-by setting the service_proxy_auth configuration item to a URL such as
-       //sp-mkws.indexdata.com/service-proxy/?command=auth&action=perconfig&username=mike&password=swordfish
+by setting the `service_proxy_auth` configuration item to a URL such as
+`//sp-mkws.indexdata.com/service-proxy/?command=auth&action=perconfig&username=mike&password=swordfish`
 
-### It should be possible to add the username and password to the
-configuration without needing to repeat the rest of the URL.
+> TODO It should be possible to add the username and password to the
+> configuration without needing to repeat the rest of the URL.
 
-Stage D (optional): conceal credentials from HTML source
+### Stage D (optional): conceal credentials from HTML source
 
 Using a credential-based Service-Proxy authentication URL such as the
 one above reveals the the credentials to public view -- to anyone who
@@ -161,13 +162,15 @@ to that local authentication URL. Here is one way to do it when
 Apache2 is the application's web-server, which we will call
 yourname.com:
 
-       - Add a rewriting authentication alias to the configuration:
-               RewriteEngine on
-               RewriteRule /spauth/ http://mkws.indexdata.com/service-proxy/?command=auth&action=check,login&username=U&password=PW [P]
-       - Set thwe MKWS configuration item "service_proxy_auth" to:
-               http://yourname.com/spauth/
-       - Protect access to the local path http://yourname.com/spauth/
-               (e.g. using a .htaccess file).
+- Add a rewriting authentication alias to the configuration:
+
+       RewriteEngine on
+       RewriteRule /spauth/ http://mkws.indexdata.com/service-proxy/?command=auth&action=check,login&username=U&password=PW [P]
+
+- Set the MKWS configuration item `service_proxy_auth` to
+  `http://yourname.com/spauth/`
+- Protect access to the local path `http://yourname.com/spauth/`
+  (e.g. using a .htaccess file).
 
 
 3. Choosing targets from the library