[Catalyst] Catalyst Manual/Tut PDF
Dear All, Would anyone with access to the main site be willing to do: http://use.perl.org/~Yanick/journal/33807 And upload the gerenated PDF? Thanks, Gavin. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] RFC: Multiple :Chained and/or :PathPart attributes?
Currently, attempting to pass multiple arguments to either Chained or
PathPart attributes in a controller simply results in an exception
being thrown indicating that you can't do that, I'm thinking it might
be useful to change that behavior to allow for multiple arguments to
simply build multiple chains that take the same path. As an example,
here is the code that led me to this thinking...
I was working on an application that includes page revisioning, and
ended up with this code, which seems excessively verbose to me...
The requirements were:
* Wiki-like page structure
* /page/SomePage displays the current revision of SomePage
* /page/SomePage/revision/3 displays revision number 3 of SomePage
* /page/SomePage/rev/3 also displays revision number 3 of SomePage
* /page/SomePage/date/2007-01-01 displays whatever revision was
current on 2007-01-01 (or show a selector if there was more than one
change that day)
* /page/SomePage/datetime/2007-01-01T12:10:00 displays whatever
revision was current at that time
* For ALL of the above URLs, the page should be displayed if there
are no other path parts, or if the URL ends with /view
These requirements led to this code...
sub page : Chained('/') PathPart('page') CaptureArgs(1) {
my ( $self, $c, $page ) = @_;
# load page data for the indicated page into the stash
}
sub revision : Chained('page') PathPart('revision') CaptureArgs(1) {
my ( $self, $c, $rev ) = @_;
$c->forward( 'handle_revision', [ $rev ] );
}
sub rev : Chained('page') PathPart('rev') CaptureArgs(1) {
my ( $self, $c, $rev ) = @_;
$c->forward( 'handle_revision', [ $rev ] );
}
sub handle_revision : Private {
my ( $self, $c ) = @_;
# load the revision indicated in $c->request->args[0] into the stash
}
sub date : Chained('page') PathPart('date') CaptureArgs(1) {
my ( $self, $c, $date ) = @_;
$c->forward( 'handle_datetime', [ $date ] );
}
sub datetime : Chained('page') PathPart('datetime') CaptureArgs(1) {
my ( $self, $c, $date ) = @_;
$c->forward( 'handle_datetime', [ $date ] );
}
sub handle_datetime : Private {
my ( $self, $c ) = @_;
# create a datetime object from $c->request->args->[0]
# load the appropriate revision into the stash
}
sub view : Chained('page') PathPart('view') Args(0) {
my ( $self, $c ) = @_;
$c->forward( 'process_view' );
}
# All of these subs have the exact same body as 'view', which does
nothing but forward to 'process_view'
sub view_default : Chained('page') PathPart('') Args(0) {
sub view_revision : Chained('revision') PathPart('view') Args(0) {}
sub view_revision_default : Chained('revision') PathPart('') Args(0) {}
sub view_rev : Chained('rev') PathPart('view') Args(0) {}
sub view_rev_default : Chained('rev') PathPart('') Args(0) {}
sub view_date : Chained('date') PathPart('view') Args(0) {}
sub view_date_default : Chained('date') PathPart('') Args(0) {}
sub view_datetime : Chained('datetime') PathPart('view') Args(0) {}
sub view_datetime_default : Chained('datetime') PathPart('') Args(0) {}
sub process_view : Private {
my ( $self, $c ) = @_;
if ( $c->stash->{ 'matches' } ) {
$c->stash->{ 'template' } = 'select_revision.tt';
} elsif ( $c->stash->{ 'page' } ) {
$c->stash->{ 'template' } = 'display_page.tt';
} else {
$c->stash->{ 'template' } = 'not_found.tt';
}
}
If the Chained and PathPart attributes could take multiple arguments
that would simply build multiple chains, then I could have
significantly reduced the amount of repetition, by doing something
along these lines instead...
sub page : Chained('/') PathPart('page') CaptureArgs(1) {
my ( $self, $c, $page ) = @_;
# load page data for the indicated page into the stash
}
sub revision : Chained('page') PathPart('revision','rev') CaptureArgs
(1) {
my ( $self, $c, $rev ) = @_;
# load the indicated revision into the stash
}
sub date : Chained('page') PathPart('date','datetime') CaptureArgs(1) {
my ( $self, $c, $date ) = @_;
# load the appropriate revision into the stash
}
sub view : Chained('page','revision','date') PathPart('','view') Args
(0) {
my ( $self, $c ) = @_;
if ( $c->stash->{ 'matches' } ) {
$c->stash->{ 'template' } = 'select_revision.tt';
} elsif ( $c->stash->{ 'page' } ) {
$c->stash->{ 'template' } = 'display_page.tt';
} else {
$c->stash->{ 'template' } = 'not_found.tt';
}
}
I tried to put together a patch that could do this, but this is my
first trip into the innards of the dispatcher, and it looks like it's
going to take a while to wrap my brain around it, so if anyone has
suggestions on how to implement this (or reasons that it's a very bad
idea) I'd love t
Re: [Catalyst] RFC: Multiple :Chained and/or :PathPart attributes?
--- Jason Kohles <[EMAIL PROTECTED]> wrote:
> Currently, attempting to pass multiple arguments to
> either Chained or
> PathPart attributes in a controller simply results
> in an exception
> being thrown indicating that you can't do that, I'm
> thinking it might
> be useful to change that behavior to allow for
> multiple arguments to
> simply build multiple chains that take the same
> path. As an example,
> here is the code that led me to this thinking...
>
> I was working on an application that includes page
> revisioning, and
> ended up with this code, which seems excessively
> verbose to me...
>
> The requirements were:
> * Wiki-like page structure
> * /page/SomePage displays the current revision of
> SomePage
> * /page/SomePage/revision/3 displays revision
> number 3 of SomePage
> * /page/SomePage/rev/3 also displays revision
> number 3 of SomePage
> * /page/SomePage/date/2007-01-01 displays whatever
> revision was
> current on 2007-01-01 (or show a selector if there
> was more than one
> change that day)
> * /page/SomePage/datetime/2007-01-01T12:10:00
> displays whatever
> revision was current at that time
> * For ALL of the above URLs, the page should be
> displayed if there
> are no other path parts, or if the URL ends with
> /view
>
> These requirements led to this code...
>
> sub page : Chained('/') PathPart('page')
> CaptureArgs(1) {
> my ( $self, $c, $page ) = @_;
> # load page data for the indicated page into the
> stash
> }
>
> sub revision : Chained('page') PathPart('revision')
> CaptureArgs(1) {
> my ( $self, $c, $rev ) = @_;
>
> $c->forward( 'handle_revision', [ $rev ] );
> }
>
> sub rev : Chained('page') PathPart('rev')
> CaptureArgs(1) {
> my ( $self, $c, $rev ) = @_;
>
> $c->forward( 'handle_revision', [ $rev ] );
> }
>
> sub handle_revision : Private {
> my ( $self, $c ) = @_;
> # load the revision indicated in
> $c->request->args[0] into the stash
> }
>
> sub date : Chained('page') PathPart('date')
> CaptureArgs(1) {
> my ( $self, $c, $date ) = @_;
>
> $c->forward( 'handle_datetime', [ $date ] );
> }
>
> sub datetime : Chained('page') PathPart('datetime')
> CaptureArgs(1) {
> my ( $self, $c, $date ) = @_;
>
> $c->forward( 'handle_datetime', [ $date ] );
> }
>
> sub handle_datetime : Private {
> my ( $self, $c ) = @_;
> # create a datetime object from
> $c->request->args->[0]
> # load the appropriate revision into the stash
> }
>
> sub view : Chained('page') PathPart('view') Args(0)
> {
> my ( $self, $c ) = @_;
>
> $c->forward( 'process_view' );
> }
>
> # All of these subs have the exact same body as
> 'view', which does
> nothing but forward to 'process_view'
> sub view_default : Chained('page') PathPart('')
> Args(0) {
> sub view_revision : Chained('revision')
> PathPart('view') Args(0) {}
> sub view_revision_default : Chained('revision')
> PathPart('') Args(0) {}
> sub view_rev : Chained('rev') PathPart('view')
> Args(0) {}
> sub view_rev_default : Chained('rev') PathPart('')
> Args(0) {}
> sub view_date : Chained('date') PathPart('view')
> Args(0) {}
> sub view_date_default : Chained('date') PathPart('')
> Args(0) {}
> sub view_datetime : Chained('datetime')
> PathPart('view') Args(0) {}
> sub view_datetime_default : Chained('datetime')
> PathPart('') Args(0) {}
>
> sub process_view : Private {
> my ( $self, $c ) = @_;
>
> if ( $c->stash->{ 'matches' } ) {
> $c->stash->{ 'template' } = 'select_revision.tt';
> } elsif ( $c->stash->{ 'page' } ) {
> $c->stash->{ 'template' } = 'display_page.tt';
> } else {
> $c->stash->{ 'template' } = 'not_found.tt';
> }
> }
>
> If the Chained and PathPart attributes could take
> multiple arguments
> that would simply build multiple chains, then I
> could have
> significantly reduced the amount of repetition, by
> doing something
> along these lines instead...
>
> sub page : Chained('/') PathPart('page')
> CaptureArgs(1) {
> my ( $self, $c, $page ) = @_;
> # load page data for the indicated page into the
> stash
> }
>
> sub revision : Chained('page')
> PathPart('revision','rev') CaptureArgs
> (1) {
> my ( $self, $c, $rev ) = @_;
>
> # load the indicated revision into the stash
> }
>
> sub date : Chained('page')
> PathPart('date','datetime') CaptureArgs(1) {
> my ( $self, $c, $date ) = @_;
>
> # load the appropriate revision into the stash
> }
>
> sub view : Chained('page','revision','date')
> PathPart('','view') Args
> (0) {
> my ( $self, $c ) = @_;
>
> if ( $c->stash->{ 'matches' } ) {
> $c->stash->{ 'template' } = 'select_revision.tt';
> } elsif ( $c->stash->{ 'page' } ) {
> $c->stash->{ 'template' } = 'display_page.tt';
> } else {
> $c->stash->{ 'template' } = 'not_found.tt';
>
Re: [Catalyst] Rate limiting password attacks
What's to stop the bot from grabbing the token from the home page and using it in its attack? The token has to be something the bot can't readily read, e.g., captcha. On Aug 18, 2007, at 10:11 AM, Carl Johnstone wrote: Bill Moseley wrote: Unfortunately, often want to have a login form on the home page and that page is typically static -- so can't use my token in that situation. How about using a variation of the token system. You have a token that's valid for any request that you change fairly frequently - say every 5 minutes. Then you dynamically insert that into the home page. Then to give you the effect of a static home page, use apache's mod_cache. Finally in your login form, you accept any from the last X tokens where X > 2 (you could've cached the page just before the token expires) up to whatever life you want to allow. Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/ catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: Multiple :Chained and/or :PathPart attributes?
On Mon, Aug 20, 2007 at 07:33:56AM -0700, John Napiorkowski wrote:
>
> --- Jason Kohles <[EMAIL PROTECTED]> wrote:
>
> > Currently, attempting to pass multiple arguments to
> > either Chained or
> > PathPart attributes in a controller simply results
> > in an exception
> > being thrown indicating that you can't do that, I'm
> > thinking it might
> > be useful to change that behavior to allow for
> > multiple arguments to
> > simply build multiple chains that take the same
> > path. As an example,
> > here is the code that led me to this thinking...
> >
> > I was working on an application that includes page
> > revisioning, and
> > ended up with this code, which seems excessively
> > verbose to me...
> >
> > The requirements were:
> > * Wiki-like page structure
> > * /page/SomePage displays the current revision of
> > SomePage
> > * /page/SomePage/revision/3 displays revision
> > number 3 of SomePage
> > * /page/SomePage/rev/3 also displays revision
> > number 3 of SomePage
> > * /page/SomePage/date/2007-01-01 displays whatever
> > revision was
> > current on 2007-01-01 (or show a selector if there
> > was more than one
> > change that day)
> > * /page/SomePage/datetime/2007-01-01T12:10:00
> > displays whatever
> > revision was current at that time
> > * For ALL of the above URLs, the page should be
> > displayed if there
> > are no other path parts, or if the URL ends with
> > /view
> >
> > These requirements led to this code...
> >
> > sub page : Chained('/') PathPart('page')
> > CaptureArgs(1) {
> > my ( $self, $c, $page ) = @_;
> > # load page data for the indicated page into the
> > stash
> > }
> >
> > sub revision : Chained('page') PathPart('revision')
> > CaptureArgs(1) {
> > my ( $self, $c, $rev ) = @_;
> >
> > $c->forward( 'handle_revision', [ $rev ] );
> > }
> >
> > sub rev : Chained('page') PathPart('rev')
> > CaptureArgs(1) {
> > my ( $self, $c, $rev ) = @_;
> >
> > $c->forward( 'handle_revision', [ $rev ] );
> > }
> >
> > sub handle_revision : Private {
> > my ( $self, $c ) = @_;
> > # load the revision indicated in
> > $c->request->args[0] into the stash
> > }
> >
> > sub date : Chained('page') PathPart('date')
> > CaptureArgs(1) {
> > my ( $self, $c, $date ) = @_;
> >
> > $c->forward( 'handle_datetime', [ $date ] );
> > }
> >
> > sub datetime : Chained('page') PathPart('datetime')
> > CaptureArgs(1) {
> > my ( $self, $c, $date ) = @_;
> >
> > $c->forward( 'handle_datetime', [ $date ] );
> > }
> >
> > sub handle_datetime : Private {
> > my ( $self, $c ) = @_;
> > # create a datetime object from
> > $c->request->args->[0]
> > # load the appropriate revision into the stash
> > }
> >
> > sub view : Chained('page') PathPart('view') Args(0)
> > {
> > my ( $self, $c ) = @_;
> >
> > $c->forward( 'process_view' );
> > }
> >
> > # All of these subs have the exact same body as
> > 'view', which does
> > nothing but forward to 'process_view'
> > sub view_default : Chained('page') PathPart('')
> > Args(0) {
> > sub view_revision : Chained('revision')
> > PathPart('view') Args(0) {}
> > sub view_revision_default : Chained('revision')
> > PathPart('') Args(0) {}
> > sub view_rev : Chained('rev') PathPart('view')
> > Args(0) {}
> > sub view_rev_default : Chained('rev') PathPart('')
> > Args(0) {}
> > sub view_date : Chained('date') PathPart('view')
> > Args(0) {}
> > sub view_date_default : Chained('date') PathPart('')
> > Args(0) {}
> > sub view_datetime : Chained('datetime')
> > PathPart('view') Args(0) {}
> > sub view_datetime_default : Chained('datetime')
> > PathPart('') Args(0) {}
> >
> > sub process_view : Private {
> > my ( $self, $c ) = @_;
> >
> > if ( $c->stash->{ 'matches' } ) {
> > $c->stash->{ 'template' } = 'select_revision.tt';
> > } elsif ( $c->stash->{ 'page' } ) {
> > $c->stash->{ 'template' } = 'display_page.tt';
> > } else {
> > $c->stash->{ 'template' } = 'not_found.tt';
> > }
> > }
> >
> > If the Chained and PathPart attributes could take
> > multiple arguments
> > that would simply build multiple chains, then I
> > could have
> > significantly reduced the amount of repetition, by
> > doing something
> > along these lines instead...
> >
> > sub page : Chained('/') PathPart('page')
> > CaptureArgs(1) {
> > my ( $self, $c, $page ) = @_;
> > # load page data for the indicated page into the
> > stash
> > }
> >
> > sub revision : Chained('page')
> > PathPart('revision','rev') CaptureArgs
> > (1) {
> > my ( $self, $c, $rev ) = @_;
> >
> > # load the indicated revision into the stash
> > }
> >
> > sub date : Chained('page')
> > PathPart('date','datetime') CaptureArgs(1) {
> > my ( $self, $c, $date ) = @_;
> >
> > # load the appropriate revision into the stash
> > }
> >
> > sub view : Chained('page','revision','date')
> > PathPart('','view') Args
> > (0) {
> >
RE: [Catalyst] reset session timeout
Hi! I've got the same problem. Suggestions? -Alex > -Original Message- > From: Moritz Onken [mailto:[EMAIL PROTECTED] > Sent: Saturday, August 11, 2007 7:37 PM > To: The elegant MVC web framework > Subject: [Catalyst] reset session timeout > > Hi, > > I don't know if it's a feature or a bug: > > Is use session state cookie. After I login the time when the cookie > will > expire is set to time_now + 2 hours. That's fine. But this point in > time > will never be updated whether I browse the page or not. > The point is I'll get logged out 2 hours after my login, even if do > every 5 minutes a reload of that page. > Did I miss something or should it work like this? > > Thanks, > > Moritz Onken > > ___ > List: Catalyst@lists.rawmode.org > Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst > Searchable archive: http://www.mail- > archive.com/catalyst@lists.rawmode.org/ > Dev site: http://dev.catalyst.perl.org/ smime.p7s Description: S/MIME cryptographic signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] reset session timeout
Hi, just put $c->session_expires(1); in your Root::auto method and the session will be reset Cheers Hartmaier Alexander schrieb: Hi! I've got the same problem. Suggestions? -Alex -Original Message- From: Moritz Onken [mailto:[EMAIL PROTECTED] Sent: Saturday, August 11, 2007 7:37 PM To: The elegant MVC web framework Subject: [Catalyst] reset session timeout Hi, I don't know if it's a feature or a bug: Is use session state cookie. After I login the time when the cookie will expire is set to time_now + 2 hours. That's fine. But this point in time will never be updated whether I browse the page or not. The point is I'll get logged out 2 hours after my login, even if do every 5 minutes a reload of that page. Did I miss something or should it work like this? Thanks, Moritz Onken ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail- archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Rate limiting password attacks
What's to stop the bot from grabbing the token from the home page and using it in its attack? The token has to be something the bot can't readily read, e.g., captcha. Bill said: "I have the ability to turn on form tokens on my forms, so to be able to post to a form you have to first fetch the single-use token from the form. That has been a big help with forms that send mail, but also aids in preventing reposting of forms -- in addition to redirect after post." So obviously they work for him. Anything that has an effect without causing accessibility problems for users has to be a good thing. In any case, I was just suggesting a way he could still make his existing token system work with a "static" page to save server resources. Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Rate limiting password attacks
He is referring to reposting of forms that are arrived at via the back button, e.g., breaking the cycle submit form -> click back button -> submit form -> etc. The use case is for single use forms not for security. It wouldn't do anything to prevent a bot from scraping the HTML for that token and using it to submit the form. On Aug 20, 2007, at 10:19 AM, Carl Johnstone wrote: What's to stop the bot from grabbing the token from the home page and using it in its attack? The token has to be something the bot can't readily read, e.g., captcha. Bill said: "I have the ability to turn on form tokens on my forms, so to be able to post to a form you have to first fetch the single-use token from the form. That has been a big help with forms that send mail, but also aids in preventing reposting of forms -- in addition to redirect after post." So obviously they work for him. Anything that has an effect without causing accessibility problems for users has to be a good thing. In any case, I was just suggesting a way he could still make his existing token system work with a "static" page to save server resources. Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/ catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Could I see a sample apache-style config file?
I see Matt has said that .conf will be the default as of 5.8. Could someone point me to an example file? I looked at Matt's slides, and searching the archives for such a thing is hard, but I have occasionally stumbled across short examples. I'm using DBIx::Class::Schema::Loader View:TT plus a number of constants for things like my Google API key. Barry Hoggard ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
