Bill Moseley (mo...@hank.org)

Ya, but it's valid for multiple posts.  That might be ok, but in
general, I only want one post for every one form generation (and no
post without a form being generated).

So, my forms all have a unique token that can only be used once.  If
used a second time I redisplay the form pre-filled with their post and
ask them to submit again if that's what they really intended.  That
has the benefit of catching if the form is no longer valid (due to
changes in the database from the first post).

Of course, that doesn't prevent using two browser windows, etc. but it
helps.


Let me ask a related question:

Where on the risk spectrum is CSRF compared to, say, session
hijacking?

I have an application that went from having some pages SSL encrypted
to all pages encrypted for logged in users.

I would like to only use secure cookies, but I place things in the
session that I need for both SSL and non-SSL pages (an example is a
language selection that is stored in the session).[1]

Makes me think I need $c->session and also $c->secure_session as
separate sessions and separate cookies.

I think Encode::decode_utf8() the recommended method over using the
utf8::decode call.  Perhaps something like this early in the request:

    $c->req->arguments(
        [
            map { Encode::decode_utf8($_) } @{$c->req->arguments}
        ]
    );

But, I'd be concerned about doing this.  Will all browsers encode into
utf8 octets?  You could easily make an LWP request with other
encodings.

The plugin does not decode the path, only the query parameters.[1]


I'm not clear on passing utf8 on the path -- I thought you would have
to url-encode it, but maybe the browser will do that. Although, I'm not
clear how it knows what encoding to use.


[1] also note that it doesn't decoded the body params, so if you
access those via the body_parameters request method they won't be
decoded.  Accessing them via ->parameters is ok, though.

On Fri, Sep 12, 2008 at 02:15:23PM +0200, Supra, Morne wrote:
>
> The problem that I have is that I have no idea how to push the data to a
> web page instead of pulling.

Pull with an AJAX update, perhaps.

Catalyst::Engine prepare_body_chunk() calls HTTP::Body's add() method
with chunks as they are read from the input stream.

What happens if the call to ->add($chunk); dies?  Does the input
stream get somehow flushed (up to the content_length)?  Or would the
exception bypass any flushing?

In other words, is it important that HTTP::Body's add() method (and
really, spin() ) not die and instead continue to, well, spin until all
the request data has been consumed?

I see these, too.  I've not been too worried, and I've been assuming
that Apache is just falling back to the default handler for some
reason.

There's a little info to be found with Google -- mostly others asking
the same question.

It would be nice to have these fail in a cleaner way (as far as the
logs go, at least).

I completely agree.

I suppose a "version" XMLRPC parameter in the request payload is
possible, but I'm actually leaning more toward just using separate
endpoints:

    http://localhost:3000/rpc1.2
    http://localhost:3000/rpc1.3

or

    http://localhost:3000/rpc/1.2
    http://localhost:3000/rpc/1.3

or

    http://localhost:3000/rpc?version=1.2

C::Action::REST uses "ActionClass('REST')" to specify the class for
the action.  And with a custom request class, has a custom dispatcher to
dispatch based on the request method.

Your example above does not use ActionClass.  Were you suggesting that
these XMLRPC actions have their own action class, and if so how would
the actions be setup then?

I would think the Catalyst approach would be something like this:

    sub widget : Local ActionClass('XMLRPC', 'widget.get' ) {


There's more than one approach, of course.

My current approach (w/o versioning) is to have a custom dispatcher
type (which I push onto $c->dispatcher->preload_dispatch_types).  I
also have a custom HTTP::Body type to parse the XMLRPC payload.  Once
the XMLRPC method name is known from the request the dispatcher
searches for the matching action.

But, I do like the approach of matching the action, and then using
$controller->can to try and find an appropriate version as you
suggested.

By the way, my assumption is I would have the entire XMLRPC API
versioned.  I asked about this on the XMLRPC list and it was
recommended that instead I version individual methods.  That is, have
separate method names that include a version:

    widget.1.get
    widget.2.get
    etc.

which would make the Catalyst part very simple, but I'm not sure I
like that idea of each method having a version in the method name.

I'm looking for suggestions how to best support multiple API versions
in an application.

The API and web share many controller actions.  As is not uncommon,
actions available for the API are defined with an attribute:

    sub foo : Local XMLRPC( 'foo.get' ) {

This is great for sharing code as often the API just exposes
the same functionality as the web interface.


When a new version of the web application is released then all web
users see the new version at the same time.  If an action in the new
version expects an additional new parameter then the form posting to
that action is modified at the same time.

But, the API access to an application typically needs to be backward
compatible to allow API users time to update their client applications
with the newer requirements.

So, it seems I would need multiple controller actions that are
dispatched based on some version.


Here's one idea I was kicking around:

Say I have an existing controller action that is used by the web
users, but also available as an XMLRPC API method:

    sub widget : Local XMLRPC( 'widget.get' ) {

So in a new application version that controller action is changed
and now requires a new parameter and returns new data.

In the new version I want to support the new action but remain
backward compatible.

    # fetch widget for web and API
    sub widget : Local XMLRPC( 'widget.get' ) Version( 2 ) {

    # deprecated to support old version of API
    sub widget_old : XMLRPC( 'widget.get' ) Version( 1 ) {

Then in my custom API dispatcher match method I take the version into
consideration when matching actions.


Any better suggestions?

On Fri, Jul 25, 2008 at 07:40:59AM -0500, James S. White wrote:
> I was trying to munge the paramaters in the controller,

You said argument in your original post:

    sub foo : Local {
        my ( $self, $c, $myarg ) = @_;

        $c->stash->{myarg} = $self->munge( $myarg );
        # or use chaining
    }


> I just can't figure
> out how to access the variables of a controller method in the template.

    Munged argument is [% myarg | html %]


> I'd
> be more than happy to pass the argument to a controller, and then have the
> view fetch it from the controller, and then the template read it from the view,
> If I had any idea how to dereference the variables in order to set them in
> new components. I was just trying to keep it walk before running and I keep
> tripping over my feet.

It's that wording that is tripping me up. ;)

And what happens if they never hit log out?  Or if their browser
crashes and then they try and log in again?

If you really need this feature, try it the other way around:  if
someone logs in then you invalidate their first session.

Have not been following that closely, but that looks complicated.
I would do something like this with Form::Processor:

    sub first_step : Local {
        my ( $self, $c ) = @_;

        return $c->post_redirect( 'second_step' )
            if $c->update_from_form;
    }


    sub second_step : Local {
        my ( $self, $c ) = @_;

        return $c->redirect( 'first_step' )
            unless $c->session->{first_step};

        return $c->post_redirect( 'third_step' )
            if $c->update_from_form;

    }


    sub third_step : Local {
        my ( $self, $c ) = @_;

        return $c->redirect( 'second_step' )
            unless $c->session->{second_step};

        return $c->post_redirect( '/home', 'Thanks for your order' )
            if $c->update_from_form:
    }

My forms are classes, thus each form class knows to save their data in the
session (except third_step which writes all the form data).  They also
know how to pre-populate the form from a previous submission (for
example, if someone goes from form three back to form one.

update_from_form() knows the form class from the action name, and
$c->redirect and $c->post_redirect are simple short-cut methods to
build the redirect and localize any messages that end up in flash.