use Stream::Buffered;
use Hash::MultiValue;
use Scalar::Util;
-
+use Catalyst::Exception;
use Moose;
use namespace::clean -except => 'meta';
sub _build_body_data {
my ($self) = @_;
- my $content_type = $self->content_type;
+
+ # Not sure if these returns should not be exceptions...
+ my $content_type = $self->content_type || return;
+ return unless ($self->method eq 'POST' || $self->method eq 'PUT');
+
my ($match) = grep { $content_type =~/$_/i }
keys(%{$self->data_handlers});
local $_ = $fh;
return $self->data_handlers->{$match}->($fh, $self);
} else {
- return undef;
+ Catalyst::Exception->throw("$content_type is does not have an available data handler");
}
}
method. You may define addition data_handlers via a global configuration
setting. See L<Catalyst\DATA HANDLERS> for more information.
+If the POST is malformed in some way (such as undefined or not content that
+matches the content-type) we raise a L<Catalyst::Exception> with the error
+text as the message.
+
+If the POSTed content type does not match an availabled data handler, this
+will also raise an exception.
+
=head2 $req->body_parameters
Returns a reference to a hash containing body (POST) parameters. Values can
cause a hash initialization error. For a more straightforward interface see
C<< $c->req->parameters >>.
-B<NOTE> A recently discovered exploit in L<CGI> style param methods does exist
-in L<Catalyst>. Here's the whitepaper of the exploit:
+B<NOTE> Interfaces like this, which are based on L<CGI> and the C<param> method
+are now known to cause demonstrated exploits. It is highly recommended that you
+avoid using this method, and migrate existing code away from it. Here's the
+whitepaper of the exploit:
L<http://blog.gerv.net/2014/10/new-class-of-vulnerability-in-perl-web-applications/>
foo => scalar($c->req->param('foo')),
});
+Upcoming versions of L<Catalyst> will disable this interface by default and require
+you to positively enable it should you require it for backwards compatibility reasons.
+
=cut
sub param {