Jay K wrote:
That page is slightly incorrect.
In C::A::Store::Null -based class, apparently $storeclass-
>can('find_user') returns 0 (called from
C::A::Authentication::Realm.pm line 85) so Realm tries to construct
find_user by itself, without success.
Yes. Null does not implement find_user - you have to. Which is why
the wiki page says subclass and add find_user.
Hmm... I guess you should read Null.pm, especially lines 29-32.
I wonder why wiki suggests to override storage; overriding
credentials should be much more reasonable.
Either is fine, actually. The execution path for authentication is
by default:
$c->authenticate() --> $realm->authenticate() --> $credential-
>authenticate() --> $store->find_user()
For SSO - you can hook at any of those points. The store is the
easiest, really - because Credential::Password has a 'passthrough'
mode by telling it password_type='none' - effectively delegating the
entire auth process cleanly to the store's find_user method. Since
you will probably need to provide some type of user information -
overriding the store gives you the ideal spot to handle both at the
same time.
Well, I still think that SSO is for CREDENTIAL VALIDATION, so we need to
override Credential.
Actually, I've done an extremly simple SSO (but it works good enough!)
and store authenticated users in DBIx::Class, and happy with it :)
Surely one could override Realm, or Catalyst itself, or rewrite Catalyst
from scratch, but I've explained my position.
Alex.
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
