Re: [Catalyst] process a restored request

[Steve]

Thanks so much!  I'm surprised this hasn't come up more often, as it 
seems such a common thing
for an application to allow for.  FWIW, I think this would make an 
excellent tutorial, perhaps for

next advent calendar, or even the next Catalyst book! :-)

On 8/4/2010 3:09 PM, Bill Moseley wrote:



On Wed, Aug 4, 2010 at 11:22 AM, Steve > wrote:


Original post:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg01222.html

My apologies for rehashing this old post, but this is such a
*nice* thing to do for users that
I'm sort of surprised the solution hasn't been implemented as a
plugin or something, at least
so far as I can tell...

I'm trying to implement this elegant solution, but am getting
stuck with the

'just dump any POST data back out into
hidden fields in the login form, don't change the URL, and have
the login
form processed in a forward() from auto or similar rather than doing a
detach' part.


I think the suggestion was in auto always check if authenticated.  If 
not authenticated, then attempt to authenticate with existing form 
data (e.g. if a username and password have been posted).  if that 
succeeds then just continue on to the requested action.


If cannot authenticate then display a login form but also include all 
other parameters that were posted in hidden fields.  Set the action to 
post back to the original action.


Repeat.

You probably want to track the original request method (GET POST PUT 
DELETE) so that when the form is submitted (and finally authenticated) 
your action sees the original request method.


If there's upload data then you would need to handle that additionally.


My questions are as follows:
What hidden field or fields are in the login form?


One for each posted parameter.

Where in the code sample are the items stashed? (or are they stored
elsewhere?)


When rendering the form.  You are using the client as a store.

Where in the code sample do we pick up after successful
authentication in order to (forward, detach, redirect - pick one
or supply alt.)?


You don't.  if the original post was to /user (e.g. to create a new 
user) then the "login" form looks just like your normal login form, 
but the action is a POST to /user.



--
Bill Moseley
mose...@hank.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/
   




No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.851 / Virus Database: 271.1.1/3050 - Release Date: 08/04/10 
00:45:00

   


___
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] process a restored request

[Bill Moseley]

On Wed, Aug 4, 2010 at 11:22 AM, Steve  wrote:

> Original post:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg01222.html
>
> My apologies for rehashing this old post, but this is such a *nice* thing
> to do for users that
> I'm sort of surprised the solution hasn't been implemented as a plugin or
> something, at least
> so far as I can tell...
>
> I'm trying to implement this elegant solution, but am getting stuck with
> the
>
> 'just dump any POST data back out into
> hidden fields in the login form, don't change the URL, and have the login
> form processed in a forward() from auto or similar rather than doing a
> detach' part.
>

I think the suggestion was in auto always check if authenticated.  If not
authenticated, then attempt to authenticate with existing form data (e.g. if
a username and password have been posted).  if that succeeds then just
continue on to the requested action.

If cannot authenticate then display a login form but also include all other
parameters that were posted in hidden fields.  Set the action to post back
to the original action.

Repeat.

You probably want to track the original request method (GET POST PUT DELETE)
so that when the form is submitted (and finally authenticated) your action
sees the original request method.

If there's upload data then you would need to handle that additionally.



>
> My questions are as follows:
> What hidden field or fields are in the login form?
>

One for each posted parameter.



> Where in the code sample are the items stashed? (or are they stored
> elsewhere?)
>

When rendering the form.  You are using the client as a store.



> Where in the code sample do we pick up after successful
> authentication in order to (forward, detach, redirect - pick one or supply
> alt.)?
>

You don't.  if the original post was to /user (e.g. to create a new user)
then the "login" form looks just like your normal login form, but the action
is a POST to /user.



-- 
Bill Moseley
mose...@hank.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] process a restored request

[Steve]

Original post: 
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg01222.html


My apologies for rehashing this old post, but this is such a *nice* 
thing to do for users that
I'm sort of surprised the solution hasn't been implemented as a plugin 
or something, at least

so far as I can tell...

I'm trying to implement this elegant solution, but am getting stuck with the

'just dump any POST data back out into
hidden fields in the login form, don't change the URL, and have the login
form processed in a forward() from auto or similar rather than doing a
detach' part.

My questions are as follows:
What hidden field or fields are in the login form?

Where in the code sample are the items stashed? (or are they stored
elsewhere?)

Where in the code sample do we pick up after successful
authentication in order to (forward, detach, redirect - pick one or supply 
alt.)?



Full post:


 Hi,
 in my application, if a client issues a request after say 30 minutes of
 inactivity, I want to answer his request only after successfull
 authentication.

 Ideally, I would simply serialize $c->request in the session, ask for
 authentication, then if successfull restore the stored request to $c and call
 $c->dispatch. But after playing around a bit, it appears not to be that
 simple (the context is stored in the request as '_context', the body seems
 fetched only on-demand, dispatch seems to need some prepare_* methods to be
 called).

 I searched the list and only found this proposition for a similar mechanism:
 http://lists.scsys.co.uk/pipermail/catalyst/2007-February/012256.html

 Am I missing an easier way of doiing this?


Yes.

Don't try and serialize $c->req, just dump any POST data back out into
hidden fields in the login form, don't change the URL, and have the login
form processed in a forward() from auto or similar rather than doing a
detach. This is how I handle "user needs to log in to continue" across the
board and it makes life much simpler.

i.e. something like

sub auto :Private {
  my ($self, $c) = @_;
  unless ($c->user_exists) {
unless ($c->forward('try_login')) {
  $c->detach('show_login_form');
  return 0;
}
  }
  return 1;
}

sub try_login :Private {
  my ($self, $c) = @_;
  my $b = $c->req->body_parameters;
  return 0 unless $b->{__username};
  return $c->authenticate({
   username =>  $b->{__username}
   password =>  $b->{__password}
 });
}





___
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] process a restored request

[Matt S Trout]

On Fri, Jan 11, 2008 at 07:06:17PM +, Jonas Alves wrote:
> On Jan 11, 2008 6:27 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > Don't try and serialize $c->req, just dump any POST data back out into
> > hidden fields in the login form, don't change the URL, and have the login
> > form processed in a forward() from auto or similar rather than doing a
> > detach. This is how I handle "user needs to log in to continue" across the
> > board and it makes life much simpler.
> >
> > i.e. something like
> >
> > sub auto :Private {
> >   my ($self, $c) = @_;
> >   unless ($c->user_exists) {
> > unless ($c->forward('try_login')) {
> >   $c->detach('show_login_form');
> >   return 0;
> > }
> >   }
> >   return 1;
> > }
> >
> > sub try_login :Private {
> >   my ($self, $c) = @_;
> >   my $b = $c->req->body_parameters;
> >   return 0 unless $b->{__username};
> >   return $c->authenticate({
> >username => $b->{__username}
> >password => $b->{__password}
> >  });
> > }
> >
> 
> And how do you handle file uploads? Do you save them in the session?

Just keep the file in a temp dir on disk that gets cleaned out regularly
and drop an identifier into the form. Most session stores are not a good
place to store arbitrary sized files.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

___
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] process a restored request

[Jonas Alves]

On Jan 11, 2008 6:27 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 08, 2008 at 02:58:17PM -0500, [EMAIL PROTECTED] wrote:
> > Hi,
> > in my application, if a client issues a request after say 30 minutes of
> > inactivity, I want to answer his request only after successfull
> > authentication.
> >
> > Ideally, I would simply serialize $c->request in the session, ask for
> > authentication, then if successfull restore the stored request to $c and 
> > call
> > $c->dispatch. But after playing around a bit, it appears not to be that
> > simple (the context is stored in the request as '_context', the body seems
> > fetched only on-demand, dispatch seems to need some prepare_* methods to be
> > called).
> >
> > I searched the list and only found this proposition for a similar mechanism:
> > http://lists.scsys.co.uk/pipermail/catalyst/2007-February/012256.html
> >
> > Am I missing an easier way of doiing this?
>
> Yes.
>
> Don't try and serialize $c->req, just dump any POST data back out into
> hidden fields in the login form, don't change the URL, and have the login
> form processed in a forward() from auto or similar rather than doing a
> detach. This is how I handle "user needs to log in to continue" across the
> board and it makes life much simpler.
>
> i.e. something like
>
> sub auto :Private {
>   my ($self, $c) = @_;
>   unless ($c->user_exists) {
> unless ($c->forward('try_login')) {
>   $c->detach('show_login_form');
>   return 0;
> }
>   }
>   return 1;
> }
>
> sub try_login :Private {
>   my ($self, $c) = @_;
>   my $b = $c->req->body_parameters;
>   return 0 unless $b->{__username};
>   return $c->authenticate({
>username => $b->{__username}
>password => $b->{__password}
>  });
> }
>

And how do you handle file uploads? Do you save them in the session?

-- 
Jonas

___
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] process a restored request

[Matt S Trout]

On Tue, Jan 08, 2008 at 02:58:17PM -0500, [EMAIL PROTECTED] wrote:
> Hi,
> in my application, if a client issues a request after say 30 minutes of 
> inactivity, I want to answer his request only after successfull 
> authentication.
> 
> Ideally, I would simply serialize $c->request in the session, ask for 
> authentication, then if successfull restore the stored request to $c and call 
> $c->dispatch. But after playing around a bit, it appears not to be that 
> simple (the context is stored in the request as '_context', the body seems 
> fetched only on-demand, dispatch seems to need some prepare_* methods to be 
> called).
> 
> I searched the list and only found this proposition for a similar mechanism:
> http://lists.scsys.co.uk/pipermail/catalyst/2007-February/012256.html
> 
> Am I missing an easier way of doiing this?

Yes.

Don't try and serialize $c->req, just dump any POST data back out into
hidden fields in the login form, don't change the URL, and have the login
form processed in a forward() from auto or similar rather than doing a
detach. This is how I handle "user needs to log in to continue" across the
board and it makes life much simpler.

i.e. something like

sub auto :Private {
  my ($self, $c) = @_;
  unless ($c->user_exists) {
unless ($c->forward('try_login')) {
  $c->detach('show_login_form');
  return 0;
}
  }
  return 1;
}

sub try_login :Private {
  my ($self, $c) = @_;
  my $b = $c->req->body_parameters;
  return 0 unless $b->{__username};
  return $c->authenticate({
   username => $b->{__username}
   password => $b->{__password}
 });
}

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

___
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] process a restored request

[catalyst]

> Just a stupid thought...having not look at continuation...
> What if $c->request have freeze/thaw hooks?
... and a way to tell catalyst to unwind processing and start over with the
thawed request.

-- 
Julien Gervais-Bird

___
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] process a restored request

[Christopher H. Laco]

[EMAIL PROTECTED] wrote:
>> Catalyst::Plugin::Continuation should do that. But it appears to be
>> broken with the current Catalyst version. Or at least I was not able
>> to make it work.
> 
> Catalyst::Plugin::Continuation would have been perfect (it even has a test 
> case that suits my needs: 
> http://search.cpan.org/src/NUFFIN/Catalyst-Plugin-Continuation-0.01/t/05_login_example.t
>  ), 
> but I haven't been able to make it work either. 
> 
> At the moment, I am not comfortable enough with the inner workings of 
> Catalyst 
> to fix the module myself. Maybe later...
> 

Just a stupid thought...having not look at continuation...
What if $c->request have freeze/thaw hooks?



signature.asc
Description: OpenPGP digital signature
___
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] process a restored request

[catalyst]

> Catalyst::Plugin::Continuation should do that. But it appears to be
> broken with the current Catalyst version. Or at least I was not able
> to make it work.

Catalyst::Plugin::Continuation would have been perfect (it even has a test 
case that suits my needs: 
http://search.cpan.org/src/NUFFIN/Catalyst-Plugin-Continuation-0.01/t/05_login_example.t
 ), 
but I haven't been able to make it work either. 

At the moment, I am not comfortable enough with the inner workings of Catalyst 
to fix the module myself. Maybe later...

-- 
Julien Gervais-Bird

___
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] process a restored request

[Jonas Alves]

On Jan 8, 2008 7:58 PM,  <[EMAIL PROTECTED]> wrote:
> Hi,
> in my application, if a client issues a request after say 30 minutes of
> inactivity, I want to answer his request only after successfull
> authentication.
>
> Ideally, I would simply serialize $c->request in the session, ask for
> authentication, then if successfull restore the stored request to $c and call
> $c->dispatch. But after playing around a bit, it appears not to be that
> simple (the context is stored in the request as '_context', the body seems
> fetched only on-demand, dispatch seems to need some prepare_* methods to be
> called).
>
> I searched the list and only found this proposition for a similar mechanism:
> http://lists.scsys.co.uk/pipermail/catalyst/2007-February/012256.html
>
> Am I missing an easier way of doiing this?
>
> Julien Gervais-Bird
>

Catalyst::Plugin::Continuation should do that. But it appears to be
broken with the current Catalyst version. Or at least I was not able
to make it work.

-- 
Jonas

___
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/