[Catalyst-commits] r9028 - in trunk/Catalyst-Plugin-Authentication: . lib/Catalyst/Authentication lib/Catalyst/Plugin

[t0m at dev.catalyst.perl.org]

Author: t0m
Date: 2009-01-07 18:13:57 +0000 (Wed, 07 Jan 2009)
New Revision: 9028

Modified:
   trunk/Catalyst-Plugin-Authentication/Changes
   trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Authentication/Store.pod
   trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Plugin/Authentication.pm
Log:
Fix broken POD

Modified: trunk/Catalyst-Plugin-Authentication/Changes
===================================================================
--- trunk/Catalyst-Plugin-Authentication/Changes	2009-01-07 10:36:53 UTC (rev 9027)
+++ trunk/Catalyst-Plugin-Authentication/Changes	2009-01-07 18:13:57 UTC (rev 9028)
@@ -1,5 +1,9 @@
 Revision history for Perl extension Catalyst::Plugin::Authentication
 
+      - Fix POD escaping, from RT#38694 (Luke Ross)
+      - Change authentication backwards compatibility handling to not rely on
+        Class::Data::Inheritable side effects, and so be Catalyst 5.80 safe (t0m)
+
 0.10009 2008-11-27
         - Including progressive realm for multiple authentication attempts
           in a single request.

Modified: trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Authentication/Store.pod
===================================================================
--- trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Authentication/Store.pod	2009-01-07 10:36:53 UTC (rev 9027)
+++ trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Authentication/Store.pod	2009-01-07 18:13:57 UTC (rev 9028)
@@ -78,7 +78,7 @@
 C<from_session> method. When the user object is saved in the session the
 C<for_session> method is called, and that is used as the value in the session
 (typically a user id). The store is also saved in the hash. If
-C<<$user->store>> returns something registered, that store's name is used. If
+C<< $user->store >> returns something registered, that store's name is used. If
 not, the user's class is used as if it were a store (and must also support
 C<from_session>).
 

Modified: trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Plugin/Authentication.pm
===================================================================
--- trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Plugin/Authentication.pm	2009-01-07 10:36:53 UTC (rev 9027)
+++ trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Plugin/Authentication.pm	2009-01-07 18:13:57 UTC (rev 9028)
@@ -575,7 +575,7 @@
 
 When user input is transferred to the L<Catalyst> application
 (typically via form inputs) the application may pass this information
-into the authentication system through the C<<$c->authenticate()>>
+into the authentication system through the C<< $c->authenticate() >>
 method.  From there, it is passed to the appropriate Credential
 verifier.
 
@@ -651,7 +651,6 @@
         	            }
         	        }
                 };
-    
 
 This tells the authentication plugin what realms are available, which
 credential and store modules are used, and the configuration of each. With
@@ -685,13 +684,13 @@
 
 The credential verifier will attempt to retrieve the user whose
 details match the authentication information provided to
-C<<$c->authenticate()>>. Once it fetches the user the password is
+C<< $c->authenticate() >>. Once it fetches the user the password is
 checked and if it matches the user will be B<authenticated> and
-C<<$c->user>> will contain the user object retrieved from the store.
+C<< $c->user >> will contain the user object retrieved from the store.
 
 In the above case, the default realm is checked, but we could just as easily
 check an alternate realm. If this were an admin login, for example, we could
-authenticate on the admin realm by simply changing the C<<$c->authenticate()>>
+authenticate on the admin realm by simply changing the C<< $c->authenticate() >>
 call:
 
     if ( $c->authenticate( { username => $user, 
@@ -716,8 +715,8 @@
     }
 
 (Note that if you have multiple realms, you can use
-C<<$c->user_in_realm('realmname')>>) in place of
-C<<$c->user_exists();>> This will essentially perform the same
+C<< $c->user_in_realm('realmname') >> in place of
+C<< $c->user_exists(); >> This will essentially perform the same
 verification as user_exists, with the added requirement that if there
 is a user, it must have come from the realm specified.)
 
@@ -870,7 +869,7 @@
 
 =head2 $c->logout( )
 
-Logs the user out. Deletes the currently logged in user from C<<$c->user>> and the session.
+Logs the user out. Deletes the currently logged in user from C<< $c->user >> and the session.
 
 =head2 $c->find_user( $userinfo, $realm )