Re: [Catalyst] question about authorization and roles
What do you get in debug console output?
By code (Catalyst::Plugin::Authorization::Roles) you have to see
something like this:
Role denied: @roles
Anyway, you should look into Catalyst::Plugin::Authorization::Roles
and try debug it, code is simple.
On 10 February 2015 at 11:01, Luca Ferrari fluca1...@infinito.it wrote:
Ciao,
this is what I did in order to get more info:
# in the controller
if ( ! $c-check_any_user_role( qw/Admin Manutentore/ ) ) {
$c-stash-{ message } = User exists . $c-user_exists() .
- with username . $c-user-username . and roles \
. $c-user-roles_to_string . and the check is .
$c-check_any_user_role( qw/Admin Manutentore/ );
my @roles = $c-user-users_roles-all();
@roles = map { $_-role-pk . = . $_-role-description }
@roles;
$c-stash-{ message } .= Roles [@roles];
}
and what is printed is:
User exists 1 - with username fluca1978 and roles [Manutentore] and
the check is 0Roles [12 = Manutentore]
so:
1) the user exists
2) the username is correct
3) the user has one role, the description of the role is matched
4) the check_any_user_role reports false (0)
5) the lookup of all the roles reports the right primary key and description.
Any idea about what I'm missing?
Thanks,
Luca
On Mon, Feb 9, 2015 at 9:43 PM, Luca Ferrari fluca1...@infinito.it wrote:
Ciao,
On Mon, Feb 9, 2015 at 6:12 PM, Jeff Black jeffrey.bl...@yahoo.com wrote:
Perhaps it's a stupid question, but have you checked that the user exists?
if ( $c-user_exists() ...
Apparently it exists because I print the username and its role list to
check...and of course the role is there.
Luca
___
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/
--
//wbr, Dmitry L.
___
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] question about authorization and roles
Ciao,
this is what I did in order to get more info:
# in the controller
if ( ! $c-check_any_user_role( qw/Admin Manutentore/ ) ) {
$c-stash-{ message } = User exists . $c-user_exists() .
- with username . $c-user-username . and roles \
. $c-user-roles_to_string . and the check is .
$c-check_any_user_role( qw/Admin Manutentore/ );
my @roles = $c-user-users_roles-all();
@roles = map { $_-role-pk . = . $_-role-description }
@roles;
$c-stash-{ message } .= Roles [@roles];
}
and what is printed is:
User exists 1 - with username fluca1978 and roles [Manutentore] and
the check is 0Roles [12 = Manutentore]
so:
1) the user exists
2) the username is correct
3) the user has one role, the description of the role is matched
4) the check_any_user_role reports false (0)
5) the lookup of all the roles reports the right primary key and description.
Any idea about what I'm missing?
Thanks,
Luca
On Mon, Feb 9, 2015 at 9:43 PM, Luca Ferrari fluca1...@infinito.it wrote:
Ciao,
On Mon, Feb 9, 2015 at 6:12 PM, Jeff Black jeffrey.bl...@yahoo.com wrote:
Perhaps it's a stupid question, but have you checked that the user exists?
if ( $c-user_exists() ...
Apparently it exists because I print the username and its role list to
check...and of course the role is there.
Luca
___
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] How to get default()-like behavior outside of the Root controller
Hi Trevor,
* Trevor Leffler tleff...@uw.edu [2015-02-07 00:00]:
Requests for non-extant paths fall through to Root-default(), which
gives the (undesired) default root view. I tried giving my top-level
controllers their own default() methods, but as others have found [1],
'default() : Path' has precedence over 'index : Chained'.
package MyApp::Admin;
sub default : Chained('base') PathPart('') { ... }
package MyApp::Survey;
sub default : Chained('base') PathPart('') { ... }
Note how you don’t specify any particular number of arguments. So it
will match any number of trailing URL segments.
I *think* this will work. I haven’t tried it.
However, contrary to what you claimed, splitting the app into multiple
Cat apps joined together at the PSGI level *will* also work just fine.
That will lead to requests for /admin/* always being dispatched to
MyApp::Admin – which gets to have its own MyApp::Admin::Controller::Root
with a `default` action that applies only to it. Likewise requests for
/survey/* will always be dispatched to MyApp::Survey which equally has
its own root controller with a `default` action that applies only to it.
If the parts of your app are not closely related, this will be a more
natural structure.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.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] How to get default()-like behavior outside of the Root controller
Hi Aristotle,
On 02/10/2015 02:39 AM, Aristotle Pagaltzis wrote:
Hi Trevor,
* Trevor Leffler tleff...@uw.edu [2015-02-07 00:00]:
Requests for non-extant paths fall through to Root-default(), which
gives the (undesired) default root view. I tried giving my top-level
controllers their own default() methods, but as others have found [1],
'default() : Path' has precedence over 'index : Chained'.
package MyApp::Admin;
sub default : Chained('base') PathPart('') { ... }
package MyApp::Survey;
sub default : Chained('base') PathPart('') { ... }
Note how you don’t specify any particular number of arguments. So it
will match any number of trailing URL segments.
I *think* this will work. I haven’t tried it.
I had tried this earlier with poor results. However, I spun up a quick
Foo catalyst project for testing and found that if I defined *all* the
defaults()'s as :Chained in Root/Admin/Survey/etc. then they played well
with my other methods, all of which are :Chained. Once you go
:Chained... ;)
However, contrary to what you claimed, splitting the app into multiple
Cat apps joined together at the PSGI level *will* also work just fine.
That will lead to requests for /admin/* always being dispatched to
MyApp::Admin – which gets to have its own MyApp::Admin::Controller::Root
with a `default` action that applies only to it. Likewise requests for
/survey/* will always be dispatched to MyApp::Survey which equally has
its own root controller with a `default` action that applies only to it.
If the parts of your app are not closely related, this will be a more
natural structure.
I don't think I spoke against splitting my app up, rather I just ignored
that line of thought. ;) There may be too many
relationships/dependencies across the major areas to split it up in the
immediate future, but I can see some architectural advantages to doing
so. Simply the fact that I've got variations in template wrappers may
be an indicator.
Thanks,
--Trevor
Regards,
___
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] How to get default()-like behavior outside of the Root controller
It turns out the length of the chaining is a variable in this equation.
In my Test Controller...
This gives good behavior:
sub base : Chained('/') PathPart('test') CaptureArgs(0) {}
sub another : Chained('base') PathPart('') CaptureArgs(0) {}
sub index : Chained('another') PathPart('') Args(0) {...}
sub default : Chained('another') PathPart('') Args() { ... }
But this gives too much weight to default, allowing it to win over
index():
sub index : Chained('another') PathPart('') Args(0) {...}
sub default : Chained('base') PathPart('') Args() { ... }
So, the shorter chain wins, eh? This latter scenario is more common for
me. I'll look into having my index() $c-forward to the bits I need.
--Trevor
On 02/10/2015 02:19 PM, Trevor Leffler wrote:
Hi Aristotle,
On 02/10/2015 02:39 AM, Aristotle Pagaltzis wrote:
Hi Trevor,
* Trevor Leffler tleff...@uw.edu [2015-02-07 00:00]:
Requests for non-extant paths fall through to Root-default(), which
gives the (undesired) default root view. I tried giving my top-level
controllers their own default() methods, but as others have found [1],
'default() : Path' has precedence over 'index : Chained'.
package MyApp::Admin;
sub default : Chained('base') PathPart('') { ... }
package MyApp::Survey;
sub default : Chained('base') PathPart('') { ... }
Note how you don’t specify any particular number of arguments. So it
will match any number of trailing URL segments.
I *think* this will work. I haven’t tried it.
I had tried this earlier with poor results. However, I spun up a quick
Foo catalyst project for testing and found that if I defined *all* the
defaults()'s as :Chained in Root/Admin/Survey/etc. then they played well
with my other methods, all of which are :Chained. Once you go
:Chained... ;)
However, contrary to what you claimed, splitting the app into multiple
Cat apps joined together at the PSGI level *will* also work just fine.
That will lead to requests for /admin/* always being dispatched to
MyApp::Admin – which gets to have its own MyApp::Admin::Controller::Root
with a `default` action that applies only to it. Likewise requests for
/survey/* will always be dispatched to MyApp::Survey which equally has
its own root controller with a `default` action that applies only to it.
If the parts of your app are not closely related, this will be a more
natural structure.
I don't think I spoke against splitting my app up, rather I just ignored
that line of thought. ;) There may be too many
relationships/dependencies across the major areas to split it up in the
immediate future, but I can see some architectural advantages to doing
so. Simply the fact that I've got variations in template wrappers may
be an indicator.
Thanks,
--Trevor
Regards,
___
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/
