[jboss-cvs] jboss-seam/doc/reference/en/modules ...

[Peter Muir]

  User: pmuir   
  Date: 07/10/11 18:41:03

  Modified:    doc/reference/en/modules  security.xml
  Log:
  JBSEAM-2081
  
  Revision  Changes    Path
  1.76      +6 -6      jboss-seam/doc/reference/en/modules/security.xml
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: security.xml
  ===================================================================
  RCS file: /cvsroot/jboss/jboss-seam/doc/reference/en/modules/security.xml,v
  retrieving revision 1.75
  retrieving revision 1.76
  diff -u -b -r1.75 -r1.76
  --- security.xml	11 Oct 2007 12:06:41 -0000	1.75
  +++ security.xml	11 Oct 2007 22:41:03 -0000	1.76
  @@ -878,7 +878,7 @@
         <para>
           And here's an example of an entity permission rule that checks if the authenticated user is allowed to insert
           a new <literal>MemberBlog</literal> record (from the seamspace example).  The entity for which the security
  -        check is being made is automatically asserted into the working memory (in this case <literal>MemberBlog</literal>):
  +        check is being made is automatically inserted into the working memory (in this case <literal>MemberBlog</literal>):
         </para>
         
         <programlisting><![CDATA[rule InsertMemberBlog
  @@ -1067,19 +1067,19 @@
           to "delete" within the working memory.  What is the working memory?  It is a session-scoped object that contains 
           the contextual information that is required by the rules engine to make a decision about a permission check.
           Each time the <literal>hasPermission()</literal> method is called, a temporary <literal>PermissionCheck</literal>
  -        object, or <emphasis>Fact</emphasis>, is asserted into the working memory.  This <literal>PermissionCheck</literal>
  +        object, or <emphasis>Fact</emphasis>, is inserted into the working memory.  This <literal>PermissionCheck</literal>
           corresponds exactly to the permission that is being checked, so for example if you call 
           <literal>hasPermission("account", "create", null)</literal> then a <literal>PermissionCheck</literal>
           object with a <literal>name</literal> equal to "account" and <literal>action</literal> equal to "create" will be
  -        asserted into the working memory for the duration of the permission check.
  +        inserted into the working memory for the duration of the permission check.
         </para>
         
         <para>
  -        So what else is in the working memory?  Besides the short-lived temporary facts asserted during a permission
  +        So what else is in the working memory?  Besides the short-lived temporary facts inserted during a permission
           check, there are some longer-lived objects in the working memory that stay there for the entire duration of
           a user being authenticated.  These include any <literal>java.security.Principal</literal> objects that
           are created as part of the authentication process, plus a <literal>org.jboss.seam.security.Role</literal>
  -        object for each of the roles that the user is a member of.  It is also possible to assert additional 
  +        object for each of the roles that the user is a member of.  It is also possible to insert additional 
           long-lived facts into the working memory by calling <literal>((RuleBasedIdentity) RuleBasedIdentity.instance()).getSecurityContext().insert()</literal>,
           passing the object as a parameter.
         </para>
  @@ -1094,7 +1094,7 @@
         
         <para>
           This condition simply states that there must be a <literal>Role</literal> object with
  -        a <literal>name</literal> of "admin" within the working memory.  As mentioned, user roles are asserted 
  +        a <literal>name</literal> of "admin" within the working memory.  As mentioned, user roles are inserted 
           into the working memory as long-lived facts.  So, putting both conditions together, this rule is essentially 
           saying "I will fire if you are checking for the <literal>customer:delete</literal> permission and the user
           is a member of the <literal>admin</literal> role".