[seam-commits] Seam SVN: r10330 - trunk/doc/Seam_Reference_Guide/en-US.
seam-commits at lists.jboss.org
seam-commits at lists.jboss.org
Tue Apr 7 00:54:31 EDT 2009
Author: shane.bryzak at jboss.com
Date: 2009-04-07 00:54:30 -0400 (Tue, 07 Apr 2009)
New Revision: 10330
Modified:
trunk/doc/Seam_Reference_Guide/en-US/Security.xml
Log:
JBSEAM-3664
Modified: trunk/doc/Seam_Reference_Guide/en-US/Security.xml
===================================================================
--- trunk/doc/Seam_Reference_Guide/en-US/Security.xml 2009-04-07 04:48:27 UTC (rev 10329)
+++ trunk/doc/Seam_Reference_Guide/en-US/Security.xml 2009-04-07 04:54:30 UTC (rev 10330)
@@ -3235,59 +3235,68 @@
A <literal>ResolverChain</literal> contains an ordered list of <literal>PermissionResolver</literal>s, for the
purpose of resolving object permissions for a particular object class or permission target.
</para>
+
+ <para>
+ The default <literal>ResolverChain</literal> consists of all permission resolvers discovered during
+ application deployment. The <literal>org.jboss.seam.security.defaultResolverChainCreated</literal>
+ event is raised (and the <literal>ResolverChain</literal> instance passed as an event parameter)
+ when the default <literal>ResolverChain</literal> is created. This allows additional resolvers that
+ for some reason were not discovered during deployment to be added, or for resolvers that are in the
+ chain to be re-ordered or removed.
+ </para>
- <para>
- The following sequence diagram shows the interaction between the components of the permission framework during a
- permission check (explanation follows). A permission check can originate from a number of possible sources,
- for example - the security interceptor, the <literal>s:hasPermission</literal> EL function, or via an API
- call to <literal>Identity.checkPermission</literal>:
- </para>
+ <para>
+ The following sequence diagram shows the interaction between the components of the permission framework during a
+ permission check (explanation follows). A permission check can originate from a number of possible sources,
+ for example - the security interceptor, the <literal>s:hasPermission</literal> EL function, or via an API
+ call to <literal>Identity.checkPermission</literal>:
+ </para>
+
+ <mediaobject>
+ <imageobject role="fo">
+ <imagedata fileref="images/security-permission-sequence.png" align="center"/>
+ </imageobject>
+ <imageobject role="html">
+ <imagedata fileref="images/security-permission-sequence.png" align="center"/>
+ </imageobject>
+ </mediaobject>
- <mediaobject>
- <imageobject role="fo">
- <imagedata fileref="images/security-permission-sequence.png" align="center"/>
- </imageobject>
- <imageobject role="html">
- <imagedata fileref="images/security-permission-sequence.png" align="center"/>
- </imageobject>
- </mediaobject>
-
- <itemizedlist>
- <listitem>
- <para>
- 1. A permission check is initiated somewhere (either in code or via an EL
- expression) resulting in a call to <literal>Identity.hasPermission()</literal>.
- </para>
- </listitem>
- <listitem>
- <para>
- 1.1. <literal>Identity</literal> invokes
- <literal>PermissionMapper.resolvePermission()</literal>, passing in the
- permission to be resolved.
- </para>
- </listitem>
- <listitem>
- <para>
- 1.1.1. <literal>PermissionMapper</literal> maintains a <literal>Map</literal> of
- <literal>ResolverChain</literal> instances, keyed by class. It uses this map
- to locate the correct <literal>ResolverChain</literal> for the permission's
- target object. Once it has the correct <literal>ResolverChain</literal>, it
- retrieves the list of <literal>PermissionResolver</literal>s it contains via
- a call to <literal>ResolverChain.getResolvers()</literal>.
- </para>
- </listitem>
- <listitem>
- <para>
- 1.1.2. For each <literal>PermissionResolver</literal> in the <literal>ResolverChain</literal>,
- the <literal>PermissionMapper</literal> invokes its <literal>hasPermission()</literal> method,
- passing in the permission instance to be checked. If any of the <literal>PermissionResolver</literal>s
- return <literal>true</literal>, then the permission check has succeeded and the
- <literal>PermissionMapper</literal> also returns <literal>true</literal> to <literal>Identity</literal>.
- If none of the <literal>PermissionResolver</literal>s return true, then the permission check
- has failed.
- </para>
- </listitem>
- </itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ 1. A permission check is initiated somewhere (either in code or via an EL
+ expression) resulting in a call to <literal>Identity.hasPermission()</literal>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 1.1. <literal>Identity</literal> invokes
+ <literal>PermissionMapper.resolvePermission()</literal>, passing in the
+ permission to be resolved.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 1.1.1. <literal>PermissionMapper</literal> maintains a <literal>Map</literal> of
+ <literal>ResolverChain</literal> instances, keyed by class. It uses this map
+ to locate the correct <literal>ResolverChain</literal> for the permission's
+ target object. Once it has the correct <literal>ResolverChain</literal>, it
+ retrieves the list of <literal>PermissionResolver</literal>s it contains via
+ a call to <literal>ResolverChain.getResolvers()</literal>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 1.1.2. For each <literal>PermissionResolver</literal> in the <literal>ResolverChain</literal>,
+ the <literal>PermissionMapper</literal> invokes its <literal>hasPermission()</literal> method,
+ passing in the permission instance to be checked. If any of the <literal>PermissionResolver</literal>s
+ return <literal>true</literal>, then the permission check has succeeded and the
+ <literal>PermissionMapper</literal> also returns <literal>true</literal> to <literal>Identity</literal>.
+ If none of the <literal>PermissionResolver</literal>s return true, then the permission check
+ has failed.
+ </para>
+ </listitem>
+ </itemizedlist>
</sect3>
</sect2>
More information about the seam-commits
mailing list