From: David Schmidt <davewood@gmx.at>
Date: Wed, 29 Sep 2010 15:32:51 +0000 (+0000)
Subject: clarify user and user_exists behaviour
X-Git-Tag: v0.10017~2
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Plugin-Authentication.git;a=commitdiff_plain;h=c51e5a950638bba0fae6e7703aa091fc6d26f407

clarify user and user_exists behaviour
---

diff --git a/lib/Catalyst/Plugin/Authentication.pm b/lib/Catalyst/Plugin/Authentication.pm
index 4898277..32c5b5a 100644
--- a/lib/Catalyst/Plugin/Authentication.pm
+++ b/lib/Catalyst/Plugin/Authentication.pm
@@ -863,14 +863,20 @@ default realm is checked.
 =head2 $c->user( )
 
 Returns the currently logged in user, or undef if there is none.
+Normally the user is re-retrieved from the store.
+For L<Catalyst::Authentication::Store::DBIx::Class> the user is re-restored 
+using the primary key of the user table. 
+Thus B<user> can throw an error even though B<user_exists>
+returned true.
 
 =head2 $c->user_exists( )
 
 Returns true if a user is logged in right now. The difference between
-user_exists and user is that user_exists will return true if a user is logged
+B<user_exists> and B<user> is that user_exists will return true if a user is logged
 in, even if it has not been yet retrieved from the storage backend. If you only
 need to know if the user is logged in, depending on the storage mechanism this
 can be much more efficient.
+B<user_exists> only looks into the session while B<user> is trying to restore the user.
 
 =head2 $c->user_in_realm( $realm )