I am very new to Perl and was just assigned the quick task to change the reCAPTCHA to reCAPTCHA v2.
On my local machine this works fine, however when I push the new version of the login form to the webhost, the form does not seem to work. I get the following error:
AH01215: Can't use string ("") as a HASH ref while "strict refs" in use at login_new.cgi line 68, line 1.: [........]
The code snippet is based on the documentation I found here: https://metacpan.org/pod/Captcha::reCAPTCHA::V2
And according to the error log my error is somewhere in here (line 68):
if ($submit) {
my $response = $cgi->param('g-recaptcha-response');
my $result = $captcha->verify($captcha_private_key, $response );
if ($result->{success}) # This is line 68
{....}
This is quite confusing to me, especially since it is working on my local machine. Could you please help? Best regards and thank you in advance!
The Verify Function has a bug. I just looked at the implementation. in case that "$res" isn't 'successful' it wont give you back the wanted hash reference.
As a quick workaround I would check if your my $result is equal to "" if thats the case the verify function failed.
In the long run you should probably submit that bug to the creator of the module.
disclaimer: I havent downloaded the module and just looked at the source without actually trying my workaround so take it with a grain of salt and try it in a safe environment first
sub verify {
my ($self, $secret, $response, $remoteip) = #_;
# ... more code here, removed for better readability
my $res = $self->{ua}->post_form(
$self->{verify_api},
$params
);
if ($res->{success}) {
my $content = decode_json $res->{content};
if ($content->{success}){
return { success => 1 };
} else {
return { success => 0, error_codes => $content->{'error-codes'} };
}
}
}
Whenever I POST something to a page with Catalyst::Controller::WrapCGI I notice that my old CGI script doesn't get any POST data.. Data inside the body of the HTTP request. What am I doing wrong and how do I fix this?
In my case, this was because I was using Catalyst::Controller::WrapCGI v0.35 and Catalyst::Controller::REST. This created a problem.. My configuration looked like this,
package MyApp::Controller::REST;
__PACKAGE__->config(namespace => '');
BEGIN { extends 'Catalyst::Controller::REST' }
and
package MyApp::Controller::Root;
__PACKAGE__->config(namespace => '');
BEGIN { extends 'Catalyst::Controller::WrapCGI' }
However, Catalyst::Controller::REST installs a begin action on line 298
sub begin : ActionClass('Deserialize') { }
And, that -- in my case -- was delegating to Catalyst::Action::Deserialize::JSON which is smart enough to seek($body,0,0) but too dumb and inconsiderate to do that for the next guy down the chain.... Code below from here
if(openhandle $body) {
seek($body, 0, 0); # in case something has already read from it
while ( defined( my $line = <$body> ) ) {
$rbody .= $line;
}
}
And, to make matters even worse, the next guy down the chain in this example is Catalyst::Controller::WrapCGI which not just fails to clean up for the next guy, but fails to set it up for itself (code from here),
if ($body) { # Slurp from body filehandle
local $/; $body_content = <$body>;
}
That should look like (at the very least)
if ($body) { # Slurp from body filehandle
local $/;
seek($body,0,0);
$body_content = <$body>;
}
That's why we can't have nice things... I opened a bug in C:C:WrapCGI to get this resolved.
in my stage server I would like to activate the debug so the clients can find errors for themselves before the app goes to the production server.
BUT I only want the first part of the message, not the Request, or the Session Data.
For example: Couldn't render template "templates/home.tt2: file error - templates/inc/heater: not found".
The message is enough for me and for my client to see that the "header" call is misspelled.
The Request has a lot of irrelevant information for the client, but also has A LOT of internal developing information that should be hidden all the time!!
Regards
What you want is to override Catalyst's dump_these method. This returns a list of things to display on Catalyst's error debugging page.
The default implementation looks like:
sub dump_these {
my $c = shift;
[ Request => $c->req ],
[ Response => $c->res ],
[ Stash => $c->stash ],
[ Config => $c->config ];
}
but you can make it more restrictive, for example
sub dump_these {
my $c = shift;
return [ Apology => "We're sorry that you encountered a problem" ],
[ Response => substr($c->res->body, 0, 512) ];
}
You would define dump_these in your app's main module -- the one where you use Catalyst.
I had a similar problem that I solved by overriding the Catalyst method log_request_parameters.
Something like this (as #mob said, put it in your main module):
sub log_request_parameters {
my $c = shift;
my %all_params = #_;
my $copy = Clone::clone(\%all_params); # don't change the 'real' request params
# Then, do anything you want to only print what matters to you,
# for example, to hide some POST parameters:
my $body = $copy->{body} || {};
foreach my $key (keys %$body) {
$body->{$key} = '****' if $key =~ /password/;
}
return $c->SUPER::log_request_parameters( %$copy );
}
But you could also simply return at the beginning, if you don't want any GET/POST parameters displayed.
Well, I didn't think of the more obvious solution, in your case: you could simply set your log level to something higher than debug, which would prevent these debug logs from being displayed, but would keep the error logs:
# (or a similar condition to check you are not on the production server)
if ( !__PACKAGE__->config->{dev} ) {
__PACKAGE__->log->levels( 'warn', 'error', 'fatal' ) if ref __PACKAGE__->log;
}
I am reading data from our Jira via SOAP and recieve an array of RemoteIssue-Objects. Now I want to iterate over these and get the status of each ticket. The documentation of RemoteIssue says that there is a getStatus()-Method. When I call it on the objects my program throws an error.
Some code:
my $soap = SOAP::Lite->uri($soap_uri)->proxy($soap_proxy);
my $login = $soap->login( $soap_user, $soap_password)->result;
if ($login) {
# This works
my $issues = $soap->getIssuesFromJqlSearch( $login, "project = \"$project\" AND fixVersion = \"$project_version\"", 500 );
if ($issues) {
foreach my $issue (#{$issues->result}) {
my $foo = $issue->getStatus(); # This doesn't work
print Dumper $foo;
}
}
}
$soap->logout();
The thrown error:
Can't locate object method "getStatus" via package "RemoteIssue" at D:\ZeuS\lib/ZeuS.pm line 81
Every other object method doesn't work either.
Does anyone know what I am doing wrong?
From what I gather, you're under the impression that you're receiving the Java object that you would manipulate on a Java consumer.
Unless $issue->getStatus() is a SOAP call (which I don't think it is) you're not dealing with the API, you're dealing with SOAP::Lite's representation in Perl of the response in XML.
getIssuesFromJqlSearch seems to be the remote call. From that, you should get $issues as a SOAP::SOM object. Which you then properly address with the result method.
This will have whatever methods are defined for the class this object is blessed into.
To see what all this object responds to try this:
use mro ();
use Scalar::Util qw<blessed>;
...
foreach my $issue (#{$issues->result}) {
say '$issue ISA ('
. join( ',', #{ mro::get_linear_isa( blessed( $issue )) } )
. ')'
;
...
}
$issue will only have those methods that have been defined for it on the Perl side.
NOTE: It is not clear from your code where ZeuS.pm comes into this thing.
I've been a proponent of adopting Moose (and MooseX::Declare) at work for several months. The style it encourages will really help the maintainability of our codebase, but not without some initial cost of learning new syntax, and especially in learning how to parse type validation errors.
I've seen discussion online of this problem, and thought I'd post a query to this community for:
a) known solutions
b) discussion of what validation error messages should look like
c) propose a proof of concept that implements some ideas
I'll also contact the authors, but I've seen some good discussion this forum too, so I thought I'd post something public.
#!/usr/bin/perl
use MooseX::Declare;
class Foo {
has 'x' => (isa => 'Int', is => 'ro');
method doit( Int $id, Str :$z, Str :$y ) {
print "doit called with id = " . $id . "\n";
print "z = " . $z . "\n";
print "y = " . $y . "\n";
}
method bar( ) {
$self->doit(); # 2, z => 'hello', y => 'there' );
}
}
my $foo = Foo->new( x => 4 );
$foo->bar();
Note the mismatch in the call to Foo::doit with the method's signature.
The error message that results is:
Validation failed for 'MooseX::Types::Structured::Tuple[MooseX::Types::Structured::Tuple[Object,Int],MooseX::Types::Structured::Dict[z,MooseX::Types::Structured::Optional[Str],y,MooseX::Types::Structured::Optional[Str]]]' failed with value [ [ Foo=HASH(0x2e02dd0) ], { } ], Internal Validation Error is: Validation failed for 'MooseX::Types::Structured::Tuple[Object,Int]' failed with value [ Foo{ x: 4 } ] at /usr/local/share/perl/5.10.0/MooseX/Method/Signatures/Meta/Method.pm line 441
MooseX::Method::Signatures::Meta::Method::validate('MooseX::Method::Signatures::Meta::Method=HASH(0x2ed9dd0)', 'ARRAY(0x2eb8b28)') called at /usr/local/share/perl/5.10.0/MooseX/Method/Signatures/Meta/Method.pm line 145
Foo::doit('Foo=HASH(0x2e02dd0)') called at ./type_mismatch.pl line 15
Foo::bar('Foo=HASH(0x2e02dd0)') called at ./type_mismatch.pl line 20
I think that most agree that this is not as direct as it could be. I've implemented a hack in my local copy of MooseX::Method::Signatures::Meta::Method that yields this output for the same program:
Validation failed for
'[[Object,Int],Dict[z,Optional[Str],y,Optional[Str]]]' failed with value [ [ Foo=HASH(0x1c97d48) ], { } ]
Internal Validation Error:
'[Object,Int]' failed with value [ Foo{ x: 4 } ]
Caller: ./type_mismatch.pl line 15 (package Foo, subroutine Foo::doit)
The super-hacky code that does this is
if (defined (my $msg = $self->type_constraint->validate($args, \$coerced))) {
if( $msg =~ /MooseX::Types::Structured::/ ) {
$msg =~ s/MooseX::Types::Structured:://g;
$msg =~ s/,.Internal/\n\nInternal/;
$msg =~ s/failed.for./failed for\n\n /g;
$msg =~ s/Tuple//g;
$msg =~ s/ is: Validation failed for/:/;
}
my ($pkg, $filename, $lineno, $subroutine) = caller(1);
$msg .= "\n\nCaller: $filename line $lineno (package $pkg, subroutine $subroutine)\n";
die $msg;
}
[Note: With a few more minutes of crawling the code, it looks like MooseX::Meta::TypeConstraint::Structured::validate is a little closer to the code that should be changed. In any case, the question about the ideal error message, and whether anyone is actively working on or thinking about similar changes stands.]
Which accomplishes 3 things:
1) Less verbose, more whitespace (I debated including s/Tuple//, but am sticking with it for now)
2) Including calling file/line (with brittle use of caller(1))
3) die instead of confess -- since as I see it the main advantage of confess was finding the user's entry point into the typechecking anyway, which we can achieve in less verbose ways
Of course I don't actually want to support this patch. My question is: What is the best way of balancing completeness and succinctness of these error messages, and are there any current plans to put something like this in place?
I'm glad you like MooseX::Declare. However, the method signature validation
errors you're talking about aren't really from there, but from
MooseX::Method::Signatures, which in turn uses MooseX::Types::Structured for
its validation needs. Every validation error you currently see comes unmodified
from MooseX::Types::Structured.
I'm also going to ignore the stack-trace part of the error message. I happen to
find them incredibly useful, and so does the rest of Moose cabal. I'm not going
to removed them by default.
If you want a way to turn them off, Moose needs to be changed to throw exception
objects instead of strings for type-constraint validation errors and possibly
other things. Those could always capture a backtrace, but the decision on
whether or not to display it, or how exactly to format it when displaying, could
be made elsewhere, and the user would be free to modify the default behaviour -
globally, locally, lexically, whatever.
What I'm going to address is building the actual validation error messages for
method signatures.
As pointed out, MooseX::Types::Structured does the actual validation
work. When something fails to validate, it's its job to raise an exception. This
exception currently happens to be a string, so it's not all that useful when
wanting to build beautiful errors, so that needs to change, similar to the issue
with stack traces above.
Once MooseX::Types::Structured throws structured exception objects, which might
look somewhat like
bless({
type => Tuple[Tuple[Object,Int],Dict[z,Optional[Str],y,Optional[Str]]],
err => [
0 => bless({
type => Tuple[Object,Int],
err => [
0 => undef,
1 => bless({
type => Int,
err => bless({}, 'ValidationError::MissingValue'),
}, 'ValidationError'),
],
}, 'ValidationError::Tuple'),
1 => undef,
],
}, 'ValidationError::Tuple')
we would have enough information available to actually correlate individual
inner validation errors with parts of the signature in MooseX::Method::Signatures. In the above example, and
given your (Int $id, Str :$z, Str :$y) signature, it'd be easy enough to know
that the very inner Validation::MissingValue for the second element of the
tuple for positional parameters was supposed to provide a value for $id, but
couldn't.
Given that, it'll be easy to generate errors such as
http://files.perldition.org/err1.png
or
http://files.perldition.org/err2.png
which is kind of what I'm going for, instead of just formatting the horrible
messages we have right now more nicely. However, if one wanted to do that, it'd
still be easy enough once we have structured validation exceptions instead of
plain strings.
None of this is actually hard - it just needs doing. If anyone feels like helping
out with this, come talk to us in #moose on irc.perl.org.
Method::Signatures::Modifiers is a package which hopes to fix some of the problems of MooseX::Method::Signatures. Simply use it to overload.
use MooseX::Declare;
use Method::Signatures::Modifiers;
class Foo
{
method bar (Int $thing) {
# this method is declared with Method::Signatures instead of MooseX::Method::Signatures
}
}