Re: [Catalyst] Hangs in RenderView in end
Tomas Doran skrev:
On 6 Jul 2009, at 05:33, Gunnar Strand wrote:
Wow, that's a fairly unexpected gotcha.
Any chance of a doc patch to make it easier for the next poor soul who
gets stuck on this?
Sure. Where would you like it?
A 'NOTES' or 'CAVEATS' section in the POD for Catalyst::View::TT is
the best place I can think of right now.
Write something and it can go somewhere else if anyone has a better idea?
Here's what I wrote, and I've attached a patch for
Catalyst::View::TT.pm. I'm very inexperienced using patches, so let me
know if you want it in any other way.
=head1 NOTES
If you are using the LCGI module inside your templates, and you
experience that the Catalyst server appears to hang while rendering
the web page, then it may be due to the debug mode of LCGI (which is
waiting for input in the terminal window). You can try turning off the
debug mode using the -no_debug option and see if that solves you
problem, eg.:
[% USE CGI('-no_debug') %]
KR,
Gunnar
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/
cgi_debug.patch
Description: Binary data
___
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/
[Catalyst] Dynamic authorization
Hi, Most of the authorization schemes appear to aim to allow authorization based on type, so that a certain group of users are allowed to CRUD a specific type of resource, eg. Albums or Artists etc. If a user has access to albums/update then the user can change any album. I have looked at the two available plugins for authorization, ACL and Roles, and both seem to support this scheme. I would like to have authorization per individual resource. A comparable example would be a member only being allowed to update her own member information. If I would implement something like this, I think I'd add a table to the database for handling authorization: Role Resource administrators members administrators blogs user1 members/update/1 user2 members/update/15 user1 blogs/update/3 user2 blogs/update/13 The table would then be consulted whenever a resource is accessed, and the lookup would be put in a central place, if possible. I've implemented a :Restricted action which handles authentication, and that is where I would try to add the authorization as well. One of the tricky things would be to have a generic way to create the resource identifier from request input. Does anyone know if this be implemented using ACL or Roles, and what are the principles for doing so? If not, what is your experience in solving this problem? KR, Gunnar ___ 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/
[Catalyst] How to do pass-through login?
Hi,
I am looking for a way to send users to the login screen if they are
trying to access a restricted path, and if the login is valid, the
original request should just continue like this:
1. myapp - GET /member/only
2. myapp - /login_form
3. myapp - POST /login
4. myapp - /member/only
I guess this is what is called pass-through login (and other actions)
in the Cookbook, but I can't understand the description:
Provide actions for these, but when they're required for something else
fill e.g. a form variable __login and have a sub begin like so:
sub begin : Private {
my ($self, $c) = @_;
foreach my $action (qw/login docommand foo bar whatever/) {
if ($c-req-params-{__${action}}) {
$c-forward($action);
}
}
}
Where is the data from the original request stored? Is everything stored
in the __$action key including any values in a form submission?
An example on how pass-through works would be very helpful.
I would have expected something like this (pseudo-code):
In begin for /member/only:
unless ( $c - user_exists() ) {
$c - delay_action(); # Saves state in Flash or Session
$c - forward('/login_form');
}
In login after authentication:
if ( $c - restore_action() ) {
$c - continue_action();
}
KR,
Gunnar
___
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 do pass-through login?
On Thu, Jul 9, 2009 at 11:03 AM, Gunnar Strandgunnarstr...@yahoo.com wrote:
Hi,
I am looking for a way to send users to the login screen if they are
trying to access a restricted path, and if the login is valid, the
original request should just continue like this:
1. myapp - GET /member/only
2. myapp - /login_form
3. myapp - POST /login
4. myapp - /member/only
I guess this is what is called pass-through login (and other actions)
in the Cookbook, but I can't understand the description:
Provide actions for these, but when they're required for something else
fill e.g. a form variable __login and have a sub begin like so:
sub begin : Private {
my ($self, $c) = @_;
foreach my $action (qw/login docommand foo bar whatever/) {
if ($c-req-params-{__${action}}) {
$c-forward($action);
}
}
}
Where is the data from the original request stored? Is everything stored
in the __$action key including any values in a form submission?
An example on how pass-through works would be very helpful.
I would have expected something like this (pseudo-code):
In begin for /member/only:
unless ( $c - user_exists() ) {
$c - delay_action(); # Saves state in Flash or Session
$c - forward('/login_form');
}
In login after authentication:
if ( $c - restore_action() ) {
$c - continue_action();
}
There is Catalyst::Helper::Auth that generates such a passthrough
login component, but it is rather buggy. You can have a look at mine
ProtoWiki code at:
http://github.com/zby/CatalystX--ProtoWiki/blob/237284a35f5fd65e3d32cb5f88b81c28a47250e9/lib/CatalystX/ProtoWiki/Controller/Auth.pm
- it is copied from the code generated by Catalyst::Helper::Auth - and
then a bit modified/fixed, but it still needs a lot of work. It
redirects to an 'url' not action - so in theory it should retain
parameters etc. - but I am not sure if they are correctly encoded now.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
___
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] New Apress book shipping now from Amazon.com
Thomas L. Shinnick wrote: Anybody going to have one of those link to Amazon from here and we'll get a donation links on their web page. (hint hint) Hmm, http://books.perl.org/ should, but doesn't...? (I'll wait until tomorrow before ordering) http://www.enlightenedperl.org/ 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] New Apress book shipping now from Amazon.com
On 09/07/2009, at 9:08 PM, Tomas Doran wrote: Thomas L. Shinnick wrote: Anybody going to have one of those link to Amazon from here and we'll get a donation links on their web page. (hint hint) Hmm, http://books.perl.org/ should, but doesn't...? (I'll wait until tomorrow before ordering) http://www.enlightenedperl.org/ Or for those of you without javascript or with adblock plus, you can buy it from the link at http://catalystframework.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] Dynamic authorization
Gunnar Strand wrote: The table would then be consulted whenever a resource is accessed, and the lookup would be put in a central place, if possible. I've implemented a :Restricted action which handles authentication, and that is where I would try to add the authorization as well. One of the tricky things would be to have a generic way to create the resource identifier from request input. I think that for the complexity of what you're doing with auth, then the authorization should be in the model layer. You should have methods on the model layer which take some form of 'user', and restrict what can be retrieved by that user. This is domain logic, so you need to build it into the domain. Does anyone know if this be implemented using ACL or Roles, and what are the principles for doing so? If not, what is your experience in solving this problem? DBIx::Class::Schema::RestrictWithObject is probably the place to start looking. 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] How to do pass-through login?
On Thu, Jul 9, 2009 at 5:03 AM, Gunnar Strandgunnarstr...@yahoo.com wrote:
Hi,
I am looking for a way to send users to the login screen if they are
trying to access a restricted path, and if the login is valid, the
original request should just continue like this:
A [rather long while ago] I rolled my own using the flash.
This happens to be the only way I use the flash in this app.
package MA:C:Root;
sub auto : Private {
my ($self, $c ) = @_;
# Exit early if going to a public path
return 1 if( grep { $c-action-reverse eq $_; } qw/login index/ );
if ( ! $c-user_exists ) {
# Save a submission the user tried to do in the flash.
# The {uri} will be redirected to after login.
# The {params} will be mapped in during that request.
if ( scalar keys % {$c-request-params} ) {
$c-flash-{params} = $c-request-params;
}
$c-flash-{uri} = $c-request-uri;
$c-response-redirect('/login');
return 0; # stop processing
}
# Restore saved params
if ( defined $c-flash-{params} and not scalar % {$c-request-params} ) {
# A submission was saved after the user logged out or (more
likely) expired.
# Populate the params with the saved values.
$c-request-params( $c-flash-{params} );
}
return 1; #continue processing
}
sub login : Local {
# Handle Auth ...
# ...
# Where to go now?
if ( scalar keys % { $c-flash } ) {
# The user has a saved action in the -flash.
# Redirect there instead and maintain any {params}
# so they can be loaded next time.
$c-response-redirect($c-flash-{uri});
$c-keep_flash(qw/params/);
} else {
$c-response-redirect('/');
}
}
###
[kind?] Comments on it's ugliness/fitness would be appreciated.
$work is such that I rarely get time to revisit code after it works
and I did this possibly 2 years go :|
HTH,
--
Nate Nuss
1. myapp - GET /member/only
2. myapp - /login_form
3. myapp - POST /login
4. myapp - /member/only
I guess this is what is called pass-through login (and other actions)
in the Cookbook, but I can't understand the description:
Provide actions for these, but when they're required for something else
fill e.g. a form variable __login and have a sub begin like so:
sub begin : Private {
my ($self, $c) = @_;
foreach my $action (qw/login docommand foo bar whatever/) {
if ($c-req-params-{__${action}}) {
$c-forward($action);
}
}
}
Where is the data from the original request stored? Is everything stored
in the __$action key including any values in a form submission?
An example on how pass-through works would be very helpful.
I would have expected something like this (pseudo-code):
In begin for /member/only:
unless ( $c - user_exists() ) {
$c - delay_action(); # Saves state in Flash or Session
$c - forward('/login_form');
}
In login after authentication:
if ( $c - restore_action() ) {
$c - continue_action();
}
KR,
Gunnar
___
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] How to do pass-through login?
On Thu, Jul 9, 2009 at 7:57 AM, Nate ogm...@gmail.com wrote:
On Thu, Jul 9, 2009 at 5:03 AM, Gunnar Strandgunnarstr...@yahoo.com
wrote:
Hi,
I am looking for a way to send users to the login screen if they are
trying to access a restricted path, and if the login is valid, the
original request should just continue like this:
A [rather long while ago] I rolled my own using the flash.
This happens to be the only way I use the flash in this app.
package MA:C:Root;
sub auto : Private {
my ($self, $c ) = @_;
# Exit early if going to a public path
return 1 if( grep { $c-action-reverse eq $_; } qw/login index/ );
if ( ! $c-user_exists ) {
# Save a submission the user tried to do in the flash.
# The {uri} will be redirected to after login.
# The {params} will be mapped in during that request.
if ( scalar keys % {$c-request-params} ) {
$c-flash-{params} = $c-request-params;
}
$c-flash-{uri} = $c-request-uri;
$c-response-redirect('/login');
return 0; # stop processing
}
# Restore saved params
if ( defined $c-flash-{params} and not scalar % {$c-request-params}
) {
# A submission was saved after the user logged out or (more
likely) expired.
# Populate the params with the saved values.
$c-request-params( $c-flash-{params} );
}
return 1; #continue processing
}
sub login : Local {
# Handle Auth ...
# ...
# Where to go now?
if ( scalar keys % { $c-flash } ) {
# The user has a saved action in the -flash.
# Redirect there instead and maintain any {params}
# so they can be loaded next time.
$c-response-redirect($c-flash-{uri});
$c-keep_flash(qw/params/);
} else {
$c-response-redirect('/');
}
}
###
[kind?] Comments on it's ugliness/fitness would be appreciated.
$work is such that I rarely get time to revisit code after it works
and I did this possibly 2 years go :|
My method uses form parameters, so I can manually craft URLs. Then in the
login controller if someone is logged in, it just continues to the redirect.
Another point is to be careful as to what destinations you allow, you don't
want to redirect to just any old URI (especially important if you using form
parameters).
-J
___
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] Dynamic authorization
Tomas Doran skrev: Gunnar Strand wrote: The table would then be consulted whenever a resource is accessed, and the lookup would be put in a central place, if possible. I've implemented a :Restricted action which handles authentication, and that is where I would try to add the authorization as well. One of the tricky things would be to have a generic way to create the resource identifier from request input. I think that for the complexity of what you're doing with auth, then the authorization should be in the model layer. You should have methods on the model layer which take some form of 'user', and restrict what can be retrieved by that user. This is domain logic, so you need to build it into the domain. Thanks, Tom. You are of course correct. Moving authorization to the data model will make it harder to show only authorized functions in the presentation layer, though. I'll have to think about this, but it seems that it is a fairly early design decision if the authorization should be in the control- or model part. And perhaps using ACL or groups will suffice. KR, Gunnar ___ 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] New Apress book shipping now from Amazon.com
The ebook is already available from APress. Got my copy last night. - Chris ___ 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/
