From: Mike Taylor <mike@indexdata.com>
Date: Tue, 1 Jul 2014 17:29:24 +0000 (+0100)
Subject: Better description of setting SP auth URL.
X-Git-Tag: 1.0.0~464
X-Git-Url: http://git.indexdata.com/?p=mkws-moved-to-github.git;a=commitdiff_plain;h=ca57eb37eb18afdf6c2abd64d60dbee32a4be695

Better description of setting SP auth URL.
---

diff --git a/doc/library-configuration.txt b/doc/library-configuration.txt
index 3b061aa..18c0cd4 100644
--- a/doc/library-configuration.txt
+++ b/doc/library-configuration.txt
@@ -43,11 +43,13 @@ in the mkws_config structure:
 2. Changing the library
 -----------------------
 
-Some MKWS applications will want to define their own library providing
-a different range of available targets. This is particularly important
-in the case of applications that authenticate onto subscription
-resources by means of credentials stored in MKAdmin, in that such
-library accounts need to prohibit unauthorised access.
+Some MKWS applications will be content to use the default library with
+its selection of targets. Most, though, will want to define their own
+library providing a different range of available targets. An important
+case is that of applications that authenticate onto subscription
+resources by means of credentials stored in MKAdmin: precautions must
+be taken so that such library accounts do not allow unauthorised
+access.
 
 Setting up such a library is a two-stage process.
 
@@ -56,7 +58,7 @@ Stage A (on MKAdmin)
 Create the library:
 	- Make a new library on http://mkc-admin.indexdata.com/console/
 	- Select relevant targets
-	- Add authentication credentials as necessary
+	- Add authentication credentials to the targets as necessary
 	- Create an end-user account
 	- Set its username and password
 
@@ -65,8 +67,14 @@ Stage B (on the application's web-server):
 Authentication onto the library can be achieved by a single HTTP GET
 to the relevant Service Proxy, passing in the credentials and thereby
 initiating an HTTP session. This can most simply be done just by
-setting service_proxy_auth to a URL such as
-	http://mkws.indexdata.com/service-proxy/?command=auth&action=login&username=MIKE&password=SWORDFISH
+setting the service_proxy_auth configuration item to a URL such as
+	http://mkws.indexdata.com/service-proxy/?command=auth&action=check,login&username=MIKE&password=SWORDFISH
+which is usually done with JavaScript like:
+
+	<script type="text/javascript">
+	  var mkws_config = { service_proxy_auth:
+	  "http://mkws.indexdata.com/service-proxy/?command=auth&action=check,login&username=MIKE&password=SWORDFISH" };
+        </script>
 
 However, doing so reveals the the credentials to public view -- to
 anyone who does View Source on the MKWS application. This may be
@@ -76,14 +84,15 @@ circumstances, a more elaborate approach is necessary. The idea is to
 make a local URL that is used for authentication onto the Service
 Proxy, hiding the credentials, and to use local mechanisms to limit
 access to that local authentication URL. Here is one way to do it when
-Apache2 is the application's web-server:
+Apache2 is the application's web-server, which we will call
+example.com:
 
 	- Add a rewriting authentication alias to the configuration:
 		RewriteEngine on
-		RewriteRule /spauth/ http://mkws.indexdata.com/service-proxy/?command=auth&action=login&username=U&password=PW [P]
-	- Extend the MKWS configuration to set service_proxy_auth:
-		http://application.com/spauth/
-	- Protect access to /apauth/ (e.g. using a .htaccess file).
+		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://example.com/spauth/
+	- Protect access to http://example.com/spauth/ (e.g. using a .htaccess file).
 
 Once such a library has been set up, and access to it established,
 target selection within the set that it makes available can be done