incubator-wookie-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r809717 - in /websites/staging/wookie/trunk/content: ./ wookie/docs/admin.html
Date Fri, 23 Mar 2012 12:35:59 GMT
Author: buildbot
Date: Fri Mar 23 12:35:59 2012
New Revision: 809717

Staging update by buildbot for wookie

    websites/staging/wookie/trunk/content/   (props changed)

Propchange: websites/staging/wookie/trunk/content/
--- cms:source-revision (original)
+++ cms:source-revision Fri Mar 23 12:35:59 2012
@@ -1 +1 @@

Modified: websites/staging/wookie/trunk/content/wookie/docs/admin.html
--- websites/staging/wookie/trunk/content/wookie/docs/admin.html (original)
+++ websites/staging/wookie/trunk/content/wookie/docs/admin.html Fri Mar 23 12:35:59 2012
@@ -78,51 +78,36 @@
   <div id="content">
-    <p>NOTE: This documentation is still in the process of being written. If you have
an questions about the Wookie administration interface, please ask on the mailing list.</p>
-<p>NOTE(2): Future versions of Wookie may not have a web interface for administration,
but be configured using command-line tools
-and/or admin clients making use of the REST API.</p>
-<h1 id="downloading_and_installing_wookie">Downloading and installing Wookie</h1>
+    <p>This is the administration guide for Wookie 0.10 and later. For earlier versions,
see the <a href="/wookie/docs/admin_9.html">Wookie 0.9.x Server Administration Guide</a>.</p>
+<p>From 0.10.0, most Wookie admin functionality is provided either by editing text
configuration files, or via the REST API. There is no longer a default web admin user interface.</p>
+<p>NOTE: This documentation is still in the process of being written. If you have an
questions about the Wookie administration interface, please ask on the mailing list.</p>
+<h1 id="downloading-and-installing-wookie">Downloading and installing Wookie</h1>
 <p>See <a href="/wookie/docs/download.html">Downloading and Installing Wookie</a></p>
-<h1 id="using_the_administration_web_interface">Using the Administration web interface</h1>
-<p>To access the administrators interface in the development server, go to</p>
-<div class="codehilite"><pre><span class="p">[</span><span class="n">http:</span><span
class="sr">//</span><span class="p">]{</span><span class="n">your</span>
<span class="n">server</span><span class="p">}</span><span class="sr">/wookie/</span><span
-<p>By default, and when Wookie is running in "standalone" mode, the Wookie server admin
username and password are both "java".</p>
-<h1 id="adding_and_removing_widgets">Adding and removing widgets</h1>
-<h2 id="adding_widgets_using_the_admin_interface">Adding widgets using the admin interface</h2>
-<p>On the admin page, click "add new widget". A page containing an upload form will
be displayed. Select the widget file you wish to deploy
-and click the "publish" button  to upload it.</p>
-<h2 id="adding_widgets_using_a_watched_folder">Adding widgets using a watched folder</h2>
+<h1 id="adding-and-updating-widgets">Adding and Updating widgets</h1>
 <p>Wookie supports the "hot deployment" of widgets by adding .wgt files to a watched
folder. The location of the folder is determined by the widget.deployfolder property. Hot-deploy
functionality is enabled by default; you can disable it if desired by setting widget.hot_deploy=false.
Note that only widgets that have a .wgt file extension will be deployed automatically.</p>
-<h1 id="removing_widgets">Removing widgets</h1>
-<p>To remove a widget, from the admin page click "Remove widget from system". This
will show a list of all widgets currently deployed with
-a link to delete widgets.</p>
-<p>Note that deleting a widget also deletes all instances and data associated with
the widget by all users.</p>
-<h1 id="widget_services_categories">Widget services (categories)</h1>
-<p>Services are deprecated.</p>
-<h1 id="whitelist_and_access_policies">Whitelist and Access Policies</h1>
+<p>Widgets can also be added using the REST API.</p>
+<h1 id="removing-widgets">Removing widgets</h1>
+<p>Deleting widgets is managed using the REST API. Note that deleting a widget also
deletes all instances and data associated with the widget by all users.</p>
+<h1 id="access-policies">Access Policies</h1>
 <p>When a Widget tries to access a third-party website or service, this is usually
prevented by the browser's
  same-origin policy. This is to prevent cross-site scripting hacks and unauthorized sharing
of personal data. 
 However, there are many instances where a Widget may legitimately want to make a call to
a third party service
  or site using AJAX, and to support this Wookie provides a server-side proxy that the Widget
can use to 
 tunnel requests through Wookie. </p>
 <p>To use the proxy, the widget author simply needs to call "widget.proxify(myurl)"
to change their service URL to one that makes use of the proxy. However, Wookie will not make
the HTTP request to take place unless the requested URL is permitted using either the global
whitelist or by an enabled Widget Access Request Policy.</p>
-<h2 id="global_whitelist">Global Whitelist</h2>
-<p>The global whitelist is accessed from the White list section of the Administrator
Menu page. From here you can view the white list, and add and remove entries. Each whitelist
entry allows ANY widget to invoke the URL you've added.</p>
-<h2 id="widget_access_request_policies">Widget Access Request Policies</h2>
-<p>Widget Access Request Policies (also known as W3C WARP; see <a href=""></a>)
is a W3C specification that allows Widgets to specify origins they wish to access in the Widget's
config.xml file.</p>
-<p>When you add a Widget to Wookie, any <code>&lt;access&gt;</code>
elements are turned into access policies that can be viewed in the Admininstrator interface.</p>
-<p>To manage WARPs, go to the White list section of the Administrator Menu page, and
select Manage widget access request policies. From this page you can view a table of policies
that have been created; the format of the table is (from left to right): the name of the widget
the policy applies to, the origin to allow, and whether the policy is granted or not granted.
Finally, there is a button to toggle the state of the policy.</p>
-<p>By default, Wookie automatically grants WARPs when installing a new Widget, and
notifies the Administrator with a message in the Admin interface and in the Wookie log file.</p>
-<h1 id="server_configuration">Server configuration</h1>
-<h2 id="user_management">User management</h2>
+<p>The proxy servlet is configured by default to operate in a whitelist mode, and is
configured using the policies text configuration file (usually found at WEB-INF/classes/policies).
There is additional documentation in the policies file itself on how to manage access policies.<br
+<p>By default, Wookie automatically adds policies specified in widget <access>
element when installing a new Widget, and notifies the Administrator with a message in the
Wookie log file.</p>
+<p>Policies can also be set via the REST API.</p>
+<h1 id="api-keys">API Keys</h1>
+<p>Wookie operates as a multi-tenancy server, with each application identified by its
API Key. There is a default API Key called "TEST" in a new Wookie installation; for each application
that connects to Wookie an API key should be created. This can be done via the REST API (e.g.
from an admin client.)</p>
+<h1 id="server-configuration">Server configuration</h1>
+<h2 id="user-management">User management</h2>
 <p>The Wookie server comes with a built-in user called "java" linked to the "widgetadmin"
role. These are defined in the and files located in WEB-INF/classes.
These can be removed in a standard application server environment, and another user added
to "widgetadmin" role, for example in tomcat-users.xml in a Tomcat installation.</p>
 <p>Login configuration settings can be found in the web.xml file located in wookie/WEB-INF.</p>
-<h2 id="integration_with_shindig">Integration with Shindig</h2>
+<h2 id="integration-with-shindig">Integration with Shindig</h2>
 <p>See <a href="/wookie/docs/shindig.html">Integrating Wookie With Shindig</a></p>
-<h2 id="proxy_configuration">Proxy configuration</h2>
+<h2 id="proxy-configuration">Proxy configuration</h2>
 <p>In order for widgets running in Wookie to communicate with external web services
using Ajax, requests must be redirected through a server-side proxy. The proxy configuration
is located in WEB-INF/classes/</p>
 <p>The following parameters can be set:</p>
 <div class="codehilite"><pre><span class="n">widget</span><span
class="o">.</span><span class="n">proxy</span><span class="o">.</span><span
class="n">usewhitelist</span><span class="o">=</span><span class="n">true</span><span
class="o">|</span><span class="n">false</span>
@@ -150,7 +135,7 @@ tunnel requests through Wookie. </p>
 <p>Use these settings to configure access control for the proxy. By default no authentication
is set.</p>
-<h1 id="mail_setup">Mail setup</h1>
+<h1 id="mail-setup">Mail setup</h1>
 <p>Wookie enables users to request API keys for their applications; these are then
sent to their email address. The email service is configured as follows:</p>
 <div class="codehilite"><pre><span class="n">widget</span><span
class="o">.</span><span class="n">email</span><span class="o">.</span><span
class="n">server</span><span class="o">=</span><span class="n">your_mail_server</span>
 <span class="n">widget</span><span class="o">.</span><span class="n">email</span><span
class="o">.</span><span class="n">port</span><span class="o">=</span><span
@@ -160,7 +145,7 @@ tunnel requests through Wookie. </p>
 <p>Username and password are optional. You can use localhost if your server is set
up to send email, e.g. using PostFix.</p>
-<h1 id="virtual_host_configuration">Virtual host configuration</h1>
+<h1 id="virtual-host-configuration">Virtual host configuration</h1>
 <p>See <a href="/wookie/docs/developer/running.html">Running Wookie</a></p>

View raw message