[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