[Catalyst] user_exists dies when used from
Test::WWW::Mechanize::Catalyst
Robert Rothenberg
robrwo at gmail.com
Mon Jun 25 14:15:28 GMT 2012
On 25/06/12 13:40 Bill Moseley wrote:
>
>
> On Mon, Jun 25, 2012 at 7:12 AM, Robert Rothenberg <robrwo at gmail.com
> <mailto:robrwo at gmail.com>> wrote:
>
>
> >
> > Do you really need the context?
>
> Yes.
>
>
> Are there times when you may wish to use your DBIC classes outside of
> Catalyst and still need access control?
> Even for cron jobs when we run them we need to set the "actor" so that the
> DBIC model code can determine if that actor is allowed to do that action.
No, because anything that is done outside of Catalyst will be done by the
"system" user.
> It's much more complex to set up and change a mock object, and have to worry
> about whether it's set up correctly, than to log in as a particular user and
> do actions that the user would normally do, and test how that affects the
> user's access permissions.
>
>
> I don't see that Test::WWW::Mechanize::Catalyst has a way to run
> ctx_request() from Catalyst::Test, but looks like a pretty easy hack. I've
> used another trick with testing where I inject a controller into the app
> only when running tests where it was much easier to run the tests in an
> acton. It's pretty rare that I need to test the context directly instead
> of the behavior of the app. I get run a test as different users and look
> for the 403 or 200 responses.
We've tried it. It's apparently not so easy.
> But, your problem is if you want to then access the database directly from
> your script you need the context -- or something that satisfies the need of
> your DBIC code.
That's not a problem. DBIC doesn't enforce access, nor does it need to. Only
the Catalyst application needs to enforce access.
> What about creating a new class with required attributes you need? Then
> build that object once per request and pass that in to your DBIC code
> instead of the context object. Then you can use that same class outside of
> Catalyst, as in your tests.
>
> I suspect others will agree that in the long run having that tight bindig
> between Catalyst and DBIC will be a mistake.
It's not a tight binding.
More information about the Catalyst
mailing list