Re: [Catalyst] Authorization Failure
On Fri, May 08, 2009 at 04:08:29PM +0400, Oleg Pronin wrote: > Catalyst and controllers are the same. Catalyst imho is _not only web_ > framework. You can beat a nail in with a screwdriver too. More seriously, I'd really like to split out the bits of Catalyst that are "application framework" rather than web so that those parts can be shared and you basically subclass it. But that's a fucktonne of code I don't have time to write just yet. If anybody wants to experiment with this idea, I'd be more than happy to help bikeshed out the design. -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.ukhttp://shadowcat.co.uk/blog/matt-s-trout/ ___ 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/
Re: [Catalyst] Authorization Failure
Tomas Doran wrote: >> I'd recommend making a TestApp, pulling the relevant bits of >> controller code out (the bodies can be mostly blank, you only care >> about the paths), setting up trivial auth (no DB or anything needed, >> just use Auth::Store::Minimal), and see if you can replicate the issue >> outside of your main application.. Ascii King wrote: > OK. I'll pull out some clear code examples. > Thanks get it Great! If you get to a TestApp, then throwing it on github is probably easiest so that people can fork it / play with it trvially. However I don't think anyone will object if you want to reduce it to test cases for the plugin in question ;) Cheers t0m ___ 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/
Re: [Catalyst] Authorization Failure
OK. I'll pull out some clear code examples. Thanks Tomas Doran wrote: Ascii King wrote: the authorization component of my application no longer works properly. Did something change with Catalyst::Plugin::Authorization? I searched the lists, but I didn't see anything. The tests still all pass, and they do test this sort of thing. When testing the above statement, admin and office are supposed to be allowed access to 'list_account'. However, admin can access it, but office and remote cannot. If I change it to 'allow_access_if' then everyone can get access. I can't really make a call about if it's working or not without knowing a lot more about your application structure, and your currently logged in user / roles etc. I'd recommend making a TestApp, pulling the relevant bits of controller code out (the bodies can be mostly blank, you only care about the paths), setting up trivial auth (no DB or anything needed, just use Auth::Store::Minimal), and see if you can replicate the issue outside of your main application.. Even if you get the same issues, you now have something small and easy to understand which you can show to other people, without them having to grok your entire app.. Cheers t0m ___ 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/ ___ 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/
Re: [Catalyst] Authorization Failure
Ascii King wrote: the authorization component of my application no longer works properly. Did something change with Catalyst::Plugin::Authorization? I searched the lists, but I didn't see anything. The tests still all pass, and they do test this sort of thing. When testing the above statement, admin and office are supposed to be allowed access to 'list_account'. However, admin can access it, but office and remote cannot. If I change it to 'allow_access_if' then everyone can get access. I can't really make a call about if it's working or not without knowing a lot more about your application structure, and your currently logged in user / roles etc. I'd recommend making a TestApp, pulling the relevant bits of controller code out (the bodies can be mostly blank, you only care about the paths), setting up trivial auth (no DB or anything needed, just use Auth::Store::Minimal), and see if you can replicate the issue outside of your main application.. Even if you get the same issues, you now have something small and easy to understand which you can show to other people, without them having to grok your entire app.. Cheers t0m ___ 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/
Re: [Catalyst] Authorization Failure
Oleg Pronin wrote:
But in TCP stream we send for example "/chess/action/make_move {JSON_DATA}"
I do not see any differences between HTTP requests and request to the
daemon. Just protocols are differ.
If you're doing something like this, then the correct solution _is_ to
be subclassing Catalyst::Engine to provide your daemon / non-HTTP protocol.
I'm currently helping develop a Catalyst engine to subscribe to Apache
ActiveMQ queues - same approach, even _less_ web like in what goes over
the wire, but it still fits a request/response model well enough to shoe
horn things in..
That is, however, totally orthogonal to having your domain logic well
factored.
Cheers
t0m
___
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/
Re: [Catalyst] Authorization Failure
Oleg Pronin wrote:
How do i should in this case read my config in script context?
use Config::General manually..
MyApp
initializes everything - memcached, dbic, uuid, json, etc.
Erm, yes, your config is gonna have memcached and dbic connection info
in it..
I wasn't aware that generating UUIDs or JSON had enough state to want to
initialize, but I may be wrong. ;)
Given you have your business/domain logic in your controllers, this
makes perfect sense, and yes - it _is_ going to be hard to initialize
stuff externally.
This is exactly why you separate everything into a model!
By writing 'use MyApp' i get everything i need. Additionally, MyApp is
complex system which consists of a lot of modules (by means of C3) and
is not only a web framework.
Erm, I have no idea what you're talking about here? MyApp ISA Plugin1,
Plugin2, Catalyst, method re-dispatch is through C3..
What plugins are you using which don't do anything web related, and why?
(As they're probably a bad idea, and would be better as models)
I would be nagged if i do not load Catalyst
at all, then i'll have to use every component from script directly
writing a lot of code instead of nice and short 'use MyApp'.
use MyModel;
MyModel->new(Config::General->new('myapp.conf')->getall->{"MyApp::MyModel"));
That isn't a lot of code?
If your actual domain model needs DBIC and/or memcached, then it's
fairly easy to set things up such that you either pass in the relevant
config (and MyModel creates the objects for you), or you pass in
pre-built instances in construction, which your model then uses. (And
you then generate the Catalyst::Model::MyModel using
Component::InstancePerContext or similar)
The former is probably preferable, as if you have a layer over DBIC
anyway, then your client code shouldn't be touching DBIC - that's
violating the law of demeter.
I'd say
than Catalyst is not _Web_ framework, it is _everything framwork_.
No, sorry - you're doing it wrong.
Catalyst is meant to be thin glue between web (or at least
request/response) stuff, and your business logic and state storage.
Classes should _always_ be standalone and validate their own state.
I'm guessing that your DBIC classes are fairly thin, and a lot of the
domain logic is in your controllers. This results in no separation of
concerns, and an anemic domain model
Not only does this tie you implicitly to the web and make testing your
code harder than it needs to be, it also ensures that you're breaking
the single responsibility principle, gives you a great headstart for
violating the law of demeter.
In my
own opinion it is better to make a little difference for scripts
(use MyApp { offline => 1 }) - which will not load web stuff and get
start lighter.
I'm not concerned with / thinking about how much code you're actually
loading - that's a purely secondary concern.
The issue is that you're being forced to jump through hoops to make
everything look like it is a web request, and the fact that you need not
one but two classes to achieve any state change - a controller to
validate that the state change is ok, and then the model to actually
store the state change - meaning that the data and code needed to
operate on whilst ensuring the data stays valid lives in different
places, not nice
but framework will stay with many features for such
scripts - for example, automatic pid file with double execution prevent,
Catalyst doesn't do this for you?
wrapping script for errors detection on log files and many other, i.e.
still framework-driven system, not script-driven.
Erm, I'm not suggesting that you should be 'script driven', which I take
to mean procedural ;)
All of my 'scripts' these days look like this:
package MyScript::Foo;
use Moose;
use MooseX::Types::Moose qw/Str/;
use namespace::autoclean;
with 'MooseX::Getopt';
has param1 => ( isa => Str, is => 'ro' );
sub run { # Do stuff here, usually a main loop, but delegating mostly to
other methods}
__PACKAGE__->meta->make_immutable;
__PACKAGE__->new_with_options->run unless caller;
A 'script' does not mean you have to throw away good OO design..
Cheers
t0m
___
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/
Re: [Catalyst] Authorization Failure
P.S.
Tomas, you explain things from position of most web sites. But imagine for
example multiplayer gaming portal written in flash.
Flash sends request through HTTP as well as through TCP stream connection
(for gaming purposes).
TCP connections served by daemon (not by Catalyst::Engine::* of course).
But in TCP stream we send for example "/chess/action/make_move {JSON_DATA}"
I do not see any differences between HTTP requests and request to the
daemon. Just protocols are differ.
Catalyst and controllers are the same. Catalyst imho is _not only web_
framework.
2009/5/8 Tomas Doran
> Oleg Pronin wrote:
>
>> Not really :-) While in request, browser header is ok, but the task is to
>> be able to authenticate in offline scripts as well - because the controllers
>> and etc read logged in user from $c->user.
>> Currently we use workaround - fake $c object + setup $c->request->header
>> for base authentication as it came from browser.
>>
>
> That's not _too much_ of a hack, given that you've got application logic in
> your controllers anyway.
>
> The recommended thing to do is to not have any application logic in your
> controllers (just have web parameter mangling related stuff). If your logic
> is all in the model, then your scripts can deal with authenticating without
> having to fake up a web request, or in fact load Catalyst at all, which is
> much nicer, and makes much more sense in a script context..
>
> Also, what do you mean by 'new Authentication',
>>Catalyst::Authentication::Credential::HTTP has _always_ worked like
>>this.
>>
>> I'm not sure but last time i used this feature (several months ago) it
>> worked fine
>>
>
> Hmm, well, if you still think I've broken something, I'd love to see a
> TestApp or test cases demonstrating what the problem is, as I'm still
> unclear.. (And if I did break it, I'd obviously like to fix it again)
>
>
> Cheers
> t0m
>
> ___
> 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/
>
___
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/
Re: [Catalyst] Authorization Failure
2009/5/8 Tomas Doran
> Oleg Pronin wrote:
>
>> Not really :-) While in request, browser header is ok, but the task is to
>> be able to authenticate in offline scripts as well - because the controllers
>> and etc read logged in user from $c->user.
>> Currently we use workaround - fake $c object + setup $c->request->header
>> for base authentication as it came from browser.
>>
>
> That's not _too much_ of a hack, given that you've got application logic in
> your controllers anyway.
>
> The recommended thing to do is to not have any application logic in your
> controllers (just have web parameter mangling related stuff). If your logic
> is all in the model, then your scripts can deal with authenticating without
> having to fake up a web request, or in fact load Catalyst at all, which is
> much nicer, and makes much more sense in a script context..
>
How do i should in this case read my config in script context ? MyApp
initializes everything - memcached, dbic, uuid, json, etc.
By writing 'use MyApp' i get everything i need. Additionally, MyApp is
complex system which consists of a lot of modules (by means of C3) and is
not only a web framework. I would be nagged if i do not load Catalyst at
all, then i'll have to use every component from script directly writing a
lot of code instead of nice and short 'use MyApp'. I'd say than Catalyst is
not _Web_ framework, it is _everything framwork_. In my own opinion it is
better to make a little difference for scripts
(use MyApp { offline => 1 }) - which will not load web stuff and get start
lighter, but framework will stay with many features for such scripts - for
example, automatic pid file with double execution prevent, wrapping script
for errors detection on log files and many other, i.e. still
framework-driven system, not script-driven.
>
>
> Also, what do you mean by 'new Authentication',
>>Catalyst::Authentication::Credential::HTTP has _always_ worked like
>>this.
>>
>> I'm not sure but last time i used this feature (several months ago) it
>> worked fine
>>
>
> Hmm, well, if you still think I've broken something, I'd love to see a
> TestApp or test cases demonstrating what the problem is, as I'm still
> unclear.. (And if I did break it, I'd obviously like to fix it again)
>
>
> Cheers
> t0m
>
> ___
> 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/
>
___
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/
Re: [Catalyst] Authorization Failure
Oleg Pronin wrote: Not really :-) While in request, browser header is ok, but the task is to be able to authenticate in offline scripts as well - because the controllers and etc read logged in user from $c->user. Currently we use workaround - fake $c object + setup $c->request->header for base authentication as it came from browser. That's not _too much_ of a hack, given that you've got application logic in your controllers anyway. The recommended thing to do is to not have any application logic in your controllers (just have web parameter mangling related stuff). If your logic is all in the model, then your scripts can deal with authenticating without having to fake up a web request, or in fact load Catalyst at all, which is much nicer, and makes much more sense in a script context.. Also, what do you mean by 'new Authentication', Catalyst::Authentication::Credential::HTTP has _always_ worked like this. I'm not sure but last time i used this feature (several months ago) it worked fine Hmm, well, if you still think I've broken something, I'd love to see a TestApp or test cases demonstrating what the problem is, as I'm still unclear.. (And if I did break it, I'd obviously like to fix it again) Cheers t0m ___ 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/
Re: [Catalyst] Authorization Failure
2009/5/8 Tomas Doran > Oleg Pronin wrote: > >> I've got problem with new Authentication too. It is said that one can pass >> login & password to authenticate call. But it somewhy no longer >> authenticates that way (in case of Credential::HTTP) >> > > Credential::HTTP doesn't work like that. > > The credentials for HTTP auth come from the browser in headers, which is > where it'll read them from. These are then mapped by your config into the > appropriate field to find your user with, and the password checked. > > If you want to pass the username/password in manually yourself (e.g. from > form submission), then you don't want Credential::HTTP. Not really :-) While in request, browser header is ok, but the task is to be able to authenticate in offline scripts as well - because the controllers and etc read logged in user from $c->user. Currently we use workaround - fake $c object + setup $c->request->header for base authentication as it came from browser. > > > Also, what do you mean by 'new Authentication', > Catalyst::Authentication::Credential::HTTP has _always_ worked like this. I'm not sure but last time i used this feature (several months ago) it worked fine > > > Cheers > t0m > > > > > ___ > 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/ > ___ 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/
Re: [Catalyst] Authorization Failure
Oleg Pronin wrote: I've got problem with new Authentication too. It is said that one can pass login & password to authenticate call. But it somewhy no longer authenticates that way (in case of Credential::HTTP) Credential::HTTP doesn't work like that. The credentials for HTTP auth come from the browser in headers, which is where it'll read them from. These are then mapped by your config into the appropriate field to find your user with, and the password checked. If you want to pass the username/password in manually yourself (e.g. from form submission), then you don't want Credential::HTTP. Also, what do you mean by 'new Authentication', Catalyst::Authentication::Credential::HTTP has _always_ worked like this. Cheers t0m ___ 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/
Re: [Catalyst] Authorization Failure
I've got problem with new Authentication too. It is said that one can pass login & password to authenticate call. But it somewhy no longer authenticates that way (in case of Credential::HTTP) 2009/5/7 Ascii King > the authorization component of my application no longer works properly. Did > something change with Catalyst::Plugin::Authorization? I searched the lists, > but I didn't see anything. > > My authorization code came from the Catalyst tutorial and I'm pretty sure > it used to work. However, I started doing some detailed checking lately and > found that it behaves erratically. If I only have one role listed in the > array (between the square brackets), it seems to work. More than one fails. > > using these: > Authentication > Authorization::Roles > Authorization::ACL > > > Here's my code. > # Authorization::ACL Rules > __PACKAGE__->allow_access_if( > "/prior/list_prior", > [qw/admin office remote/], > ); > __PACKAGE__->deny_access_if( > "/account/list_account", > [qw/admin office/], > ); > > When testing the above statement, admin and office are supposed to be > allowed access to 'list_account'. However, admin can access it, but office > and remote cannot. If I change it to 'allow_access_if' then everyone can get > access. > > > ___ > 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/ > ___ 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/
