cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [DAISY] Created: Protection
Date Sat, 13 Jan 2007 21:33:46 GMT
A new document has been created.

Document ID: 1318
Branch: main
Language: default
Name: Protection
Document Type: Cocoon Document
Created: 1/13/07 9:33:32 PM
Creator (owner): Carsten Ziegeler
State: publish


Mime type: text/xml
Size: 4806 bytes

<h2>Protecting Documents</h2>

<p>One feature of Cocoon Auth is user authentication and protecting documents. A
document can be accessible for everyone, it can be accessible by authenticated
users or the user needs more credentials than just being logged in to read it -
for example she has to be in a specific role.</p>

<p>There are several ways of protecting a document:</p>

<li>The Servlet Specification: It is possible to define URI spaces that require
an authenticated users.</li>
<li>The Sitemap: Cocoon Auth provides some actions to protect pipelines. The
checks range from testing if the user is authenticated, over if the user has a
role to more specific, custom access checks.</li>
<li>Cocoon Flow: Cocoon Auth provides some FlowScript functions that make the
same checks that are possible in a sitemap available to the flow controller.
<li>Custom Components: Cocoon Auth consists of several components, that can be
used in your own code if required.</li>

<p>Regardless which method you use, the process of requesting a document can be
described as follows:</p>

<li>The user request a document (original document).</li>
<li>Cocoon Auth checks (using one of the methods mentioned above) if this
document is protected. If no protection is specified, the response is this
original document.</li>
<li>If the document is protected, Cocoon Auth checks, if the user is
<li>If the user is authenticated, the response is the original document. If the
user is not authenticated, the application logic has to deal with this. For
example a redirect to a special page can be done. This action is freely
configurable and can for example contain information about the unauthorized
access and in addition a login form.</li>
<li>At some point, the user has to authenticate. This is usually done by
creating a login form where the user can enter the required information (e.g.
user id and password). When the user submits his data, Cocoon Auth activates the
corresponding security handler and tries to authenticate the user.</li>
<li>In case of a successful authentication a redirect to the original document
(or to any configured start document) can take place.</li>
<li>If the authentication fails another page is invoked that might
displays(error) information to the user. Again this is freely customizable.

<p>This process is only one example for a use-case of Cocoon Auth. It can be
configured for any authentication scheme and any flow. Every aspect is freely

<h2>Controlling the user access</h2>

<p>An application can be used to protected documents. It's the task of the
application developer to specifiy if a Cocoon pipeline is only accessible for
authenticated users of an application. This can be done either in the sitemap
using actions, or in flow using a component or in some custom code.</p>

<h3>Using actions</h3>

<p>Cocoon Auth provides the <em>cauth-is-logged-in</em> action to check
in the
sitemap if the user is logged in. The name of the application is required as a

<pre>&lt;map:act type="cauth-is-logged-in"&gt;
  &lt;map:parameter name="application" value="WebShop"&gt;

<p>In contrast to the authentication-fw block of Cocoon, this action doesn't
perform a redirect if the user is not logged in. It's up to the application
developer to do the appropriate action.</p>

<h3>Using flow</h3>

<p>The functionality of Cocoon Auth is available through a single component: the
<em>ApplicationManager</em>. Testing if a user is authenticated is just calling
a single method on this manager which takes the application as an argument:</p>

<pre>var appMan = cocoon.getComponent(ApplicationManager.class.getName());
if ( appMan.isLoggedIn("WebShop") ) {
  // YES, logged in
} else {
  // No, not logged in

<h3>Custom code</h3>

<p>Using custom (java) code is very similar to using flow: you lookup the
<em>ApplicationManager</em> as well and invoke the same methods.</p>

<h2>Logging out</h2>

<p>Usually a web application supports logging out of the application to free any
resources and information on the server of the current user.</p>

<h3>Using actions</h3>

<p>The logout process can be triggered by the <em>cauth-logout</em> action
requires the application name as a parameter:</p>

<pre>&lt;map:act type="cowarp-logout"&gt;
  &lt;map:parameter name="application" value="WebShop"&gt;


<h3>Using flow/Custom code</h3>

<p>Again, the application manager can be used to logout a user from an

<pre>var appMan = cocoon.getComponent(ApplicationManager.class.getName());
appMan.logout("WebShop", null);


The document belongs to the following collections: cdocs-auth

View raw message