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?