+resources).
+
+Maintaining the library
+-----------------------
+
+The Service Proxy accesses sets of targets that are known as
+"libraries". In general, each customer will have their own library,
+though some standard libraries may be shared between many customers --
+for example, a library containing all open-access academic journals.
+A library can also contain other configuration information, including
+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 "MKX Admin" installation at
+<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
+MKAdmin and administrate that library.
+
+Once logged in, customers can select which targets to include (from
+the list of several thousand that MKAdmin knows about), and make
+customer-specific modifications to the target profiles --
+e.g. overriding the titles of the targets.
+
+Most importantly, customers' administrators can add authentication
+credentials that the Service Proxy will use on their behalf when
+accessing subscription resources -- username/password pairs or proxies
+to use for IP-based authentication. Note that **it is then crucial to
+secure the library from use by unauthorised clients**, otherwise the
+customer's paid subscriptions will be exploited.
+
+Access to libraries is managed by creating one or more "User Access"
+records in MKAdmin, under the tab of that name. Each of these records
+provides a combination of credentials and other data that allow an
+incoming MKWS client to be identified as having legitimate access to
+the library. The authentication process, described below, works by
+searching for a matching User Access record.
+
+
+Authenticating your MWKS application onto the library
+-----------------------------------------------------
+
+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 back-end site 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 process of several stages.
+
+### Create the User Access account
+
+Log in to MKAdmin to add a User Access account for your library:
+
+* Go to <http://mkx-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 referring URL, or
+ IP-address range.
+
+If your MWKS application runs at a well-known, permanent address --
+<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. Then the application will always use that
+library that this User Access record is associated with (unless it
+sends a username/password pair to override this default).
+
+Or if your application's users are coming from a well-known range of
+IP-address space, you can enter the range in the "IP Ranges"
+field. The format of this field is as follows: it can contain any
+number of ranges, separated by commas; each range is either a single
+IP address or two addresses separated by a hyphen; each IP address is
+four small integers separated by periods. For example,
+`80.229.143.255-80.229.143.255, 5.57.0.0-5.57.255.255, 127.0.0.1`.
+
+Alternatively, your application can authenticate by username and
+password credentials. This is a useful approach in several situations,
+including when you need to specify the use of a different library from
+usual one. To arrange for this, set the username and password as a
+single string separated by a slash -- e.g. `mike/swordfish` -- into
+the User Access record's Authentication field.
+
+You can set multiple fields into a single User Access record; or
+create multiple User Access records. For example, a single User Access
+record can specify both a Referring URL and a username/password pair
+that can be used when running an application from a different URL. But
+if multiple Referring URLs are needed, then each must be specified in
+its own User Access record.
+
+### (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 is done
+by providing the `sp_auth_credentials` configuration setting as a string
+containing the username and password separated by a slash:
+
+ mkws_config = { sp_auth_credentials: "mike/swordfish" };
+
+### (Optional): conceal credentials from HTML source
+
+Using credential-based authentication settings such as those above
+reveals the the credentials to public view -- to anyone who does View
+Source on the MKWS application. This may be acceptable for some
+libraries, but is intolerable for those which provide authenticated
+access to subscription resources.
+
+In these circumstances, a different approach is
+necessary. Referer-based or IP-based authentication may be
+appropriate. But if these are not possible, then a more elaborate
+approach can be used to hide the credentials in a web-server
+configuration that is not visible to users.
+
+The idea is to make a Service Proxy authentication URL local to the
+customer, hiding the credentials in a rewrite rule in the local
+web-server's configuration. Then local mechanisms can be used to limit
+access 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`:
+
+Step 1: add a rewriting authentication alias to the configuration:
+
+ RewriteEngine on
+ RewriteRule /spauth/ http://sp-mkws.indexdata.com/service-proxy/\
+ ?command=auth&action=check,login&username=U&password=PW [P]
+
+Step 2: set the MKWS configuration setting `service_proxy_auth` to
+`http://yourname.com/spauth/`.
+
+Step 3: protect access to the local path `http://yourname.com/spauth/`
+(e.g. using a `.htaccess` file).
+
+
+Choosing targets from the library
+---------------------------------
+
+MKWS applications can choose what subset of the library's targets to
+use, by means of several alternative settings on individual widgets or
+in the `mkws_config` structure:
+
+* `targets` -- contains a Pazpar2 targets string, typically of the form
+ "pz:id=" or "pz:id~" followed by a pipe-separated list of low-level
+ target IDs.
+ At present, these IDs can take one of two forms, depending on the
+ configuration of the Service Proxy being used: they may be based on
+ ZURLs (so a typical value would be something like
+ `pz:id=josiah.brown.edu:210/innopac|lui.indexdata.com:8080/solr4/select?fq=database:4902`)
+ or they may be UDBs (so a typical value would be something like
+ `pz:id=brown|artstor`)
+
+* `targetfilter` -- contains a CQL query which is used to find relevant
+ targets from the relvant library. For example,
+ `udb==Google_Images`
+ or
+ `categories=news`
+
+* `target` -- contains a single UDB, that of the sole target to be
+ used. For example,
+ `Google_Images`.
+ This is merely syntactic sugar for "targetfilter" with the query
+ `udb==NAME`
+
+For example, a `Records` widget can be limited to searching only in
+targets that have been categorised as news sources by providing an
+attribute as follows:
+
+ <div class="mkws-records" targetfilter='categories=news'/>
+
+
+Reference guide
+===============
+
+Widgets
+-------
+
+The following widgets are provided in the core set. (Others can be
+added: see the [MKWS developers' guide](mkws-developer.html).)
+
+----
+Name Description
+---- -----------
+`auth-name` Initially empty, it updates itself to shows the name
+ of the library that the application is logged in as
+ when authentication is complete.
+
+`builder` A button which, when pressed, analyses the current
+ settings of the team that it is a part of, and
+ generates the HTML for an auto-searching element
+ that will replicate the present search. This HTML is
+ displayed in an alert box: it is intended that this
+ widget be subclassed to store the generated widget
+ definitions in more useful places.
+
+`button` The search button. Usually generated a `search`
+ widget.
+
+`categories` Obtains from the Service Proxy a list of the target
+ categories associated with the library in use, and
+ displays them in a drop-down list. When a category
+ is selected, searches are limited to the targets
+ that are part of that category.
+
+`config` This widget has no functionality of its own, but its
+ configuration is copied up into its team, allowing
+ it to affect other widgets in the team. This is the
+ only way to set configuration settings at the team
+ level.
+
+`console-builder` Like the `builder` widget, but emits the generated
+ HTML on the JavaScript console. This exists to
+ provide an example of how to subclass the `builder`
+ widget.
+
+`cover-art` Displays cover art for a book by searching in
+ Amazon. Often used with an `autosearch` attribute to
+ indicate what book to display. For example,
+ `<div class="mkws-cover-art" autosearch="isbn=1291177124"></div>`
+ displays cover art for _All Yesterdays: Unique and
+ Speculative Views of Dinosaurs and Other Prehistoric
+ Animals_.
+ For this widget to work, a library that includes the
+ AmazonBooks target must be used. For example, the
+ "DEMO AmazonBooks for MKWS" account, which can be
+ selected with `sp_auth_credentials="mkws-amazon/mkws"`.
+
+`details` This widget is generated by the toolkit itself to
+ hold the full details of records that are initially
+ listed in summary form.
+
+`done` Initially empty, this widget is set to display
+ "Search complete: found _n_ records" when all
+ targets have completed their work, either returning
+ a hit-count or an error. The message displayed can
+ be changed by overriding the `done` template using
+ `<script class="mkws-template-done" type="text/x-handlebars-template">`.
+
+`facet` A facet that displays the frequency with which a set
+ of terms occur within a specific field. The specific
+ field whose contents are analysed must be specified
+ by the widget's `facet` configuration setting, which
+ may conveniently be done by means of the
+ `data-mkws-facet` attribute on the HTML
+ element. The supported facets are "subject",
+ "author" and "xtargets" -- the latter a special case
+ which treats the target providing a record as a
+ facet. Most often, `facet` widgets are generated
+ by a `facets` widget, which knows which facets are
+ required, but they can also be placed individually.
+
+`facets` An area that contains a "Facets" heading and several
+ `facet` widgets. The set of facet widgets generated
+ is specified by the `facets` configuration setting,
+ which may be set globally or at the level of the
+ widget or the team. The value of this configuration
+ setting is an array of zero or more strings, each
+ naming a facet.
+
+`google-image` A specialisation of the `images` widget which
+ defaults to the `Google_Images` target.
+
+`images` A specialisation of the `records` widget which
+ defaults to the `images` template. Unlike the default
+ summary template, this displays an image from the
+ URL specified by the `md-thumburl` field of each
+ record.
+
+`lang` Provides a selection between the supported set of
+ languages (which defaults to English, German and
+ Danish, but can be configured by the `lang`
+ configuration setting, whose value is an array of
+ two-letter language codes).
+
+`log` Initially empty, this widget accumulates a log of
+ messages generated by the widget set, similar to
+ those emitted on the JavaScript console.
+
+`lolcat` A specialisation of the `google-image` widget which
+ defaults to the search-term "kitteh" and
+ auto-executes.
+
+`motd-container` An empty container which the `motd` widget, if any,
+ is moved into for initial display. Usually generated
+ as part of the `results` widget.
+
+`motd` May be provided, containing content to appear in the
+ area where records will later appear. It is moved
+ into this area (the `motd-container` widget) and
+ initially displayed; then hidden when the first
+ search is run. It can be used to provide a "message
+ of the day".
+
+`navi` Shows a list of the facets that have been selected,
+ and allows them to be deselected.
+
+`pager` Shows a list of the available pages of results, and
+ allows the user to navigate to a selected page.
+
+`per-page` Provides a dropdown allowing the user to choose how
+ many records should appear on each page. The
+ available set of page-sizes can be specified as the
+ `perpage_options` configuration setting, whose value is
+ an array of integers. The initial selected value can
+ be specified by the `perpage_default` configuration setting.
+
+`progress` Shows a progress bar which indicates how many of the
+ targets have responded to the search.
+
+`query` The input area for a query. Usually generated a `search`
+ widget.
+
+`ranking` The result-ranking area, consisting of a `sort`
+ widget and a `per-page` widget. These may instead
+ be specified separately if preferred.
+
+`record` A detailed display of a single record, usually
+ appearing when the user clicks on a summary
+ record. This is generated by the `records` widget.
+
+`records` The area in which summary records appear. (Clicking
+ on a summary record make it pop up as a detailed
+ record.)
+
+`reference` A short summary about a subject specified by the
+ `autosearch` configuration setting. This is created by
+ drawing a picture and a paragraph of text from
+ Wikipedia. To work correctly, this widget must be
+ used in a library that provides the
+ `wikimedia_wikipedia_single_result` target.
+
+`results` A large compound widget used to provide the most
+ important results-oriented widgets in a pre-packaged
+ framework: `facets`, `ranking`, `pager`, `navi` and
+ `records`.
+
+`search-form` The search form, containing the query area and the
+ button. Usually generated a `search` widget.
+
+`search` The search box, consisting of a form containing a
+ query area and a button.
+
+`sort` Provides a dropdown allowing the user to choose how
+ the displayed records should be sorted. The
+ available set of sort criteria can be specified as the
+ `sort_options` configuration setting, whose value is
+ an array of two-element arrays. The first item of
+ each sub-array is a pazpar2 sort-expression such as
+ `data:0` and the second is a human-readable label
+ such as `newest`. The initial selected
+ value can be specified by the `sort_default` configuration
+ setting.
+
+`stat` A summary line stating how many targets remain
+ active, how many records have been found, and how
+ many of them have been retrieved for display. For
+ most purposes, the `progress` widget may be
+ preferable.
+
+`summary` A short record, included in the list shown when a
+ search is run. When clicked, this generally pops up
+ a detailed `record` widget. This widget is generated
+ by the toolkit in response to search results.
+
+`switch` A pair of buttons allowing the user to switch
+ between viewing the search results (the usual case)
+ or the target list.
+
+`targets` A list of all targets in the present library,
+ showing their ID, the number of records they have
+ found for the current search, any diagnostics they
+ have returned, the number of records that have been
+ returned for display, and the connection state.
+----
+
+
+Configuration settings
+----------------------
+
+Configuration settings may be provided at the level of a indiviual widget, or a team, or globally. Per-widget configuration is
+described above; per-team settings can be placed in a `config` widget belonging to the relevant team, and will be applied to that
+team as a whole; and global settings are provided in the global variable `mkws_config`. This structure is a key-value lookup
+table, and may specify the values of many settings.
+
+Some settings apply only to specific widgets; others to the behaviour of the tookit as a whole. When a widget does not itself have
+a value specified for a particular configuration setting, its team is consulted; and if that also does not have a value, the global
+settings are consulted. Only if this, too, is unspecified, is the default value used.
+
+The supported configuration settings are described in the table below. For those settings that apply only to particular widgets,
+the relevant widgets are listed. All entries are optional, but if specified must be given values of the specified type. Long
+default values are in footnotes to keep the table reasonably narrow.
+
+----
+Element Widget Type Default Description
+-------- ------ ----- --------- ------------
+auth_hostname _global_ string If provided, overrides the `pp2_hostname` setting when constructing the
+ Service Proxy authentication URL. This need only be used when authentication
+ is performed on a different host from the remaining operations (search,
+ retrieve, etc.)
+
+autosearch facet, string If provided, this setting contains a query which is immediately run on behalf
+ facets, of the team. Often used with an [indirect setting](#indirect-settings).
+ record,
+ records,
+ results
+
+facet facet string For a `facet` widget, this setting is mandatory, and indicates which field to
+ list terms for. Three fields are supported: `subject`, `author` and
+ `xtargets` -- the latter a special case which treats the target providing a
+ record as a facet. Any other field may also be used, but the default caption
+ and maximum term-count may not be appropriate, needing to be overridden by
+ `facet_caption_*` and `facet_max_*` settings.
+
+facet_caption_* facet string Specifies what on-screen caption is to be used for the named facet: for
+ example, if a `date` facet is generated, then `facet_caption_date` can be
+ used to set the caption to "Year".
+
+facet_max_* facet int Specifies how many terms are to be displayed for the named facet: for
+ example, if a `publisher` facet is generated, then `facet_max_publisher` can
+ be used to limit the list to the top six.
+
+facets _team_ array *Note 1* Ordered list of names of facets to display.
+
+lang _team_ string Two-letter ISO code of the default language to display the UI in. Supported
+ language codes are `en` = English, `de` = German, `da` = Danish, and whatever
+ additional languages are configured using `language_*` entries (see below).
+
+lang_options lang array [] A list of the languages to offer as options. If empty (the default), then all
+ configured languages are listed.
+
+language_* _global_ hash Support for any number of languages can be added by providing entries whose
+ name is `language_` followed by the code of the language. See the separate
+ section below for details.
+
+limit facet, string Allows a partial search to be included in the specification of an
+ facets, auto-executing widget. This is ANDed with the submitted query, as though it
+ record, had been selected from a facet. See the Search section in [the Protocol
+ records, chapter of the Pazpar2 manual
+ results ](http://www.indexdata.com/pazpar2/doc/pazpar2_protocol.html)
+
+log_level _global_ int 1 Level of debugging output to emit. 0 = none, 1 = messages, 2 = messages with
+ datestamps, 3 = messages with datestamps and stack-traces.
+
+maxrecs facet, int Limits the metasearching middleware to retrieving no more than the specified
+ facets, number of records from each target.
+ record,
+ records,
+ results
+
+paragraphs reference int Limits the number of paragraphs rendered to the specified number. If
+ omitted, there is no limit.
+
+pazpar2_url _global_ string If specified, this is the URL used to access the metasearch middleware. This
+ service must be configured to provide search results, facets, etc. It may be
+ either unmediated Pazpar2 or the MasterKey Service Proxy, which mediates
+ access to an underlying Pazpar2 instance. When not specified, the URL is
+ assembled from `pp2_hostname` and `pp2_path`. See the [Assembling Pazpar2
+ URLs](#assembling-pazpar2-urls) section below.
+
+perpage facet, int Specifies the number of records to show per page in an auto-executing
+ facets, widget. Contrast with `perpage_default`, which is used to prime the dropdown
+ record, with which a user chooses the page-size in an interactive session.
+ records,
+ results
+
+perpage_default _team_ string 20 The initial value for the number of records to show on each page.
+
+perpage_options ranking array *Note 2* A list of candidate page sizes. Users can choose between these to determine
+ how many records are displayed on each page of results.
+
+pp2_hostname _global_ string *Note 3* Unless overridden by the `pazpar2_url` setting, this is used together with
+ `pp2_path` to construct the URL to the Pazpar2 service (or Service
+ Proxy). Set this to connect to a service on a different host from the
+ default.
+
+pp2_path _global_ string *Note 4* Unless overridden by the `pazpar2_url` setting, this is used together with
+ `pp2_hostname` to construct the URL to the Pazpar2 service (or Service
+ Proxy). Set this to connect to a service on a different host from the
+ default.
+
+scan_all_nodes _global_ bool false An internal setting that changes how MKWS scans the HTML documen to discover
+ widgets. If set to true, a different approach is used which may be faster
+ under some circumstances.
+
+sentences reference int Limits the number of sentences rendered to the specified number. If
+ omitted, there is no limit.
+
+service_proxy_auth _global_ url If defined, this is the URL which, when `use_service_proxy` is true, is
+ fetched once at the beginning of each session to authenticate the user and
+ establish a session that encompasses a defined set of targets to search
+ in. When not defined, the URL is assembled from `auth_hostname` or
+ `pp2_hostname`, `sp_auth_path`, `sp_auth_query` and
+ `sp_auth_credentials`. See the [Assembling Pazpar2
+ URLs](#assembling-pazpar2-urls) section below.
+
+service_proxy_auth_domain _global_ domain When the server used for authentication -- e.g. the one identified by the
+ `service_proxy_auth` URL -- proxies for different server, this can be set to
+ the domain of the server that it proxies for, so that cookies are rewritten
+ to appear to be from this domain.
+
+show_lang lang bool true Indicates whether or not to display the language menu.
+
+show_perpage ranking bool true Indicates whether or not to display the perpage menu.
+
+show_sort ranking bool true Indicates whether or not to display the sort menu.