Fix broken POD

diff --git a/Changes b/Changes
index 96ec29e..1202b8e 100644 (file)
--- a/Changes
+++ b/Changes
@@ -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.

diff --git a/lib/Catalyst/Authentication/Store.pod b/lib/Catalyst/Authentication/Store.pod
index b5c1f0f..9cd5907 100644 (file)
--- a/lib/Catalyst/Authentication/Store.pod
+++ b/lib/Catalyst/Authentication/Store.pod
@@ -78,7 +78,7 @@ If your users support sessions, your store should also define the
 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>).
 

diff --git a/lib/Catalyst/Plugin/Authentication.pm b/lib/Catalyst/Plugin/Authentication.pm
index 49ca595..da686db 100644 (file)
--- a/lib/Catalyst/Plugin/Authentication.pm
+++ b/lib/Catalyst/Plugin/Authentication.pm
@@ -575,7 +575,7 @@ realms is available in the configuration section.
 
 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 means that our application will begin like this:
                            }
                        }
                 };
-    
 
 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 @@ user is logged in.
 
 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 @@ The restricted action might look like this:
     }
 
 (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 @@ logged in right now and was retrieved from the realm provided.
 
 =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 )