Thanks for your patience, Tom Sahib. :)
We've been getting up to speed via the (Packt Publishing) book "Catalyst:
Accelerating Perl Web Application Development" by Jonathan Rockway, using
the paradigm introduced on p74. That's where we went astray:
use Catalyst qw/ConfigLoader Static::Simple
Session Session::State::Cookie Session::Store::DBIC
Authentication
Authentication::Store::DBIC
Authentication::Credential::Password
Authorization::Roles
Authorization::ACL/;
We'd lost track of the config portion:
<authentication>
default_realm = members
<realms>
<members>
<credential>
...
</credential>
<store>
class = DBIx::Class
...
</store>
</members>
</realms>
</authentication>
Feeling much better now. Thanks!
On Mon, May 31, 2010 at 10:53 AM, Tomas Doran <[email protected]> wrote:
>
> On 31 May 2010, at 16:25, [email protected] wrote:
>
> Thanks Tom. I can see now that I was a bit fuzzy on my question, whoops :)
>>
>>
>> On Mon, May 31, 2010 at 9:34 AM, Tomas Doran <[email protected]>
>> wrote:
>>
>> On 31 May 2010, at 05:16, [email protected] wrote:
>>
>> Okay, we should uninstall the deprecated modules just to be sure our
>> dependencies are all clean, and we should use Catalyst::Authentication
>> instead of Catalyst::Plugin::Authentication...
>>
>> We still use Catalyst::Plugin::Authentication to do the heavy lifting --
>> but it's not supposed to rely on
>> Catalyst::Plugin::Authentication::Store::DBIC, but rather
>> Catalyst::Authentication::Store::DBIx::Class instead, right?
>>
>> The syntax for "use Catalyst qw//" is that it prepends "Catalyst::Plugin"
>> to the beginning of any module you ask for unless you prefix it with a "+":
>>
>> use Catalyst qw/
>> Authentication
>> +Catalyst::Authentication::Store::DBIx::Class
>> /;
>>
>> Is that the recommended syntax?
>>
>>
> NO. You don't add the extra authentication stores / credentials to the
> plugin list, as they're not plugins.
>
> Plugins are overlaid onto the app (i.e. your MyApp class @ISA each of your
> plugins).
>
> The authentication credentials/stores/realms are delegate objects used to
> provide those things - your app doesn't inherit them.
>
> You set the new Plugin::Authentication up to work like this with the new
> modules in the way that is documented, which doesn't suggest anywhere doing
> anything like that ^^^.
>
>
> Would like to have a clean library with no deprecated stuff available to
>> fall back on. Disk space is cheap but that seems like saying I'll drive
>> around the countryside just for fun because gas is cheap. Trying "make
>> uninstall" didn't get me very far. Maybe there's a way to use ExtUtils to
>> create a packlist file...
>>
>
> Erm, you're going to configure different stuff in your configuration, and
> so there is no chance that the old stuff will be 'fallen back on'.
>
> The old classes won't be loaded (as you're no longer putting them in your
> plugin config) and won't be used (as if the authentication plugin does the
> loading, it won't load the old-style ::Plugin:: auth modules)..
>
>
> B) How do we make sure we're using the recommended Store/Credential
>> modules? This isn't something we specify via "use Catalyst qw/blah/" I take
>> it.
>>
>> Correct, you specify it by the authentication config (as documented in the
>> Authentication plugin)
>>
>> Documentation? You mean... read? :)
>>
>
> Yes, I mean read, try, yell when it isn't clear, patch to make it more
> clear :)
>
>
> Cheers
> t0m
>
>
> _______________________________________________
> List: [email protected]
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/[email protected]/
> Dev site: http://dev.catalyst.perl.org/
>
--
will trillich
"It's only by saying 'no' that you can concentrate on the things that are
really important." -- Steve Jobs
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
