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

[Gavin King]

  User: gavin   
  Date: 07/02/13 11:33:27

  Modified:    doc/reference/en/modules  security.xml
  Log:
  minor
  
  Revision  Changes    Path
  1.37      +13 -5     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.36
  retrieving revision 1.37
  diff -u -b -r1.36 -r1.37
  --- security.xml	13 Feb 2007 16:29:20 -0000	1.36
  +++ security.xml	13 Feb 2007 16:33:26 -0000	1.37
  @@ -246,6 +246,8 @@
         
         <programlisting><![CDATA[<pages>
     
  +    ...
  +    
       <exception class="org.jboss.seam.security.NotLoggedInException">
           <redirect view-id="/login.xhtml">
               <message>You must be logged in to perform this action</message>
  @@ -276,8 +278,12 @@
           to access a particular view (or wildcarded view id) as follows:
         </para>
         
  -      <programlisting><![CDATA[<pages" login-view-id="/login.xhtml">
  +      <programlisting><![CDATA[<pages login-view-id="/login.xhtml">
  +
       <page view-id="/members/*" login-required="true"/>
  +    
  +    ...
  +    
   </pages>]]></programlisting>
   
         <para>
  @@ -303,10 +309,10 @@
   </event>]]></programlisting>
         
         <para>
  -        It is important to note that login redirection is implemented as a conversation-scoped mechanism,
  -        meaning that for this feature to work, conversation propagation must be enabled until the user is 
  -        successfully logged in.
  +        Note that login redirection is implemented as a conversation-scoped mechanism, so don't end 
  +        the conversation in your <literal>authenticate()</literal> method.
         </para>
  +      
       </sect2>
           
       <sect2>
  @@ -347,6 +353,7 @@
   
       <sect2>
         <title>Core concepts</title>
  +      
         <para>
           Each of the authorization mechanisms provided by the Seam Security API are built upon the concept of a user
           being granted roles and/or permissions.  A role is a <emphasis>group</emphasis>, or <emphasis>type</emphasis>,
  @@ -366,6 +373,7 @@
   
       <sect2>
         <title>Securing components</title>
  +      
         <para>
           Let's start by examining the simplest form of authorization, component security, starting with the
           <literal>@Restrict</literal> annotation.