Hi Jochen, You are nearly there.
The DBIx::Class store interprets the authinfo hash (almost) exactly like the condition argument to $resultset->search(); The 'almost' bit is that it will filter out any columns that aren't actually in the user class. So - if you provide it with an authinfo hash that has no fields that match the user class - what you get is: $resultset->search(undef)->first; Which will most likely return the first user in your table. So yes... in the rather unlikely event that the passwords happen to match, will get you logged in as that user. Jay On Mar 19, 2008, at 2:08 PM, Jochen Luig wrote:
Hi Alex,It is A Feature. You've messed with parameters, username in userinfo, login in credential. my $userinfo = { login => $login, password => $password} will cure.Yes, I know. I found this out just as I was beginning to complain on #catalyst. I just wanted to know if I interpreted the behaviour (the primary key part) correctly and if my suggestion to issue a warning in such a case is off-base. Best regards, Jochen _______________________________________________ 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/
--- "Those who can make you believe absurdities can make you commit atrocities." --Voltaire _______________________________________________ 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/
