521416 - Some web servers fail to set the QUERY_STRING parameter (causing undef errors on IIS)

Status: RESOLVED FIXED

(Bugzilla :: Administration, task)

Description

[Chuck Doucette]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: 3.4.2

Software error:
Undef to trick_taint at Bugzilla/Util.pm line 62
	Bugzilla::Util::trick_taint(undef) called at Bugzilla/User.pm line 1685
	Bugzilla::User::login_to_id(undef, 1) called at Bugzilla/Component.pm line 246
	Bugzilla::Component::_check_cc_list('Bugzilla::Component', 'ARRAY(0x1aaddc4)', 'initial_cc') called at Bugzilla/Object.pm line 395
	Bugzilla::Object::run_create_validators('Bugzilla::Component', 'HASH(0x297927c)') called at Bugzilla/Component.pm line 132
	Bugzilla::Component::run_create_validators('Bugzilla::Component', 'HASH(0x297927c)') called at Bugzilla/Component.pm line 115
	Bugzilla::Component::create('Bugzilla::Component', 'HASH(0x297927c)') called at C:\bugzilla-3.4.2\editcomponents.cgi line 132

For help, please send mail to this site's webmaster, giving this error message and the time and date of the error. 

[Fri Oct 9 10:26:02 2009] editcomponents.cgi: Undef to trick_taint at Bugzilla/Util.pm line 62 [Fri Oct 9 10:26:02 2009] editcomponents.cgi: Bugzilla::Util::trick_taint(undef) called at Bugzilla/User.pm line 1685 [Fri Oct 9 10:26:02 2009] editcomponents.cgi: Bugzilla::User::login_to_id(undef, 1) called at Bugzilla/Component.pm line 246 [Fri Oct 9 10:26:02 2009] editcomponents.cgi: Bugzilla::Component::_check_cc_list('Bugzilla::Component', 'ARRAY(0x1aaddc4)', 'initial_cc') called at Bugzilla/Object.pm line 395 [Fri Oct 9 10:26:02 2009] editcomponents.cgi: Bugzilla::Object::run_create_validators('Bugzilla::Component', 'HASH(0x297927c)') called at Bugzilla/Component.pm line 132 [Fri Oct 9 10:26:02 2009] editcomponents.cgi: Bugzilla::Component::run_create_validators('Bugzilla::Component', 'HASH(0x297927c)') called at Bugzilla/Component.pm line 115 [Fri Oct 9 10:26:02 2009] editcomponents.cgi: Bugzilla::Component::create('Bugzilla::Component', 'HASH(0x297927c)') called at C:\bugzilla-3.4.2\editcomponents.cgi line 132 

Reproducible: Always

Steps to Reproduce:
1.Add a product
2.
3.

Comment 1

[Chuck Doucette]

Currently this is configured to run under IIS so I could have the option to run the ActivePerl ISAPI DLL.
I am downloading Apache now to see if that makes it work.

Comment 2

[Chuck Doucette]

When I switched to Apache - it worked fine.

Comment 3

[Chuck Doucette]

Updated summary to reflect webserver configuration that causes it (i.e. IIS).

Comment 4

[Tom Dickson]

I am now getting this on 3.4.5 on Apache:

Undef to trick_taint at /var/www/bugzilla/htdocs/Bugzilla/Util.pm line 62
	Bugzilla::Util::trick_taint('undef') called at /var/www/bugzilla/htdocs/Bugzilla/Auth/Persist/Cookie.pm line 61
	Bugzilla::Auth::Persist::Cookie::persist_login('Bugzilla::Auth::Persist::Cookie=ARRAY(0x9b09318)', 'Bugzilla::User=HASH(0x9bc6034)') called at /var/www/bugzilla/htdocs/Bugzilla/Auth.pm line 147
	Bugzilla::Auth::_handle_login_result('Bugzilla::Auth=ARRAY(0x923ea10)', 'HASH(0x830fa94)', 2) called at /var/www/bugzilla/htdocs/Bugzilla/Auth.pm line 92
	Bugzilla::Auth::login('Bugzilla::Auth=ARRAY(0x923ea10)', 2) called at /var/www/bugzilla/htdocs/Bugzilla.pm line 253
	Bugzilla::login('Bugzilla', 0) called at /var/www/bugzilla/htdocs/index.cgi line 40
	ModPerl::ROOT::Bugzilla::ModPerl::ResponseHandler::var_www_bugzilla_htdocs_index_2ecgi::handler('Apache2::RequestRec=SCALAR(0x975e514)') called at /usr/lib/perl5/vendor_perl/5.8.8/i686-linux/ModPerl/RegistryCooker.pm line 204
	eval {...} called at /usr/lib/perl5/vendor_perl/5.8.8/i686-linux/ModPerl/RegistryCooker.pm line 204
	ModPerl::RegistryCooker::run('Bugzilla::ModPerl::ResponseHandler=HASH(0x923eab8)') called at /usr/lib/perl5/vendor_perl/5.8.8/i686-linux/ModPerl/RegistryCooker.pm line 170
	ModPerl::RegistryCooker::default_handler('Bugzilla::ModPerl::ResponseHandler=HASH(0x923eab8)') called at /usr/lib/perl5/vendor_perl/5.8.8/i686-linux/ModPerl/Registry.pm line 31
	ModPerl::Registry::handler('Bugzilla::ModPerl::ResponseHandler', 'Apache2::RequestRec=SCALAR(0x975e514)') called at /var/www/bugzilla/htdocs/mod_perl.pl line 99
	Bugzilla::ModPerl::ResponseHandler::handler('Bugzilla::ModPerl::ResponseHandler', 'Apache2::RequestRec=SCALAR(0x975e514)') called at -e line 0\n\teval {...} called at -e line 0

Comment 5

[Tom Dickson]

I tried both with:

PerlConfigRequire /var/www/bugzilla/htdocs/mod_perl.pl

and with AddHandler cgi-script cgi and got the same thing.

I hadn't noticed this until I moved the server to also be on IPv6, but I suspect I hadn't logged out in a long time.

Gentoo Linux, Apache/2.2.14 (Unix) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l PHP/5.2.12-pl0-gentoo mod_perl/2.0.4 Perl/v5.8.8

Comment 6

[Tom Dickson]

Further information:

If I uncheck the "Restrict this session to this IP address (using this option improves security)" box, it fails even a normal login.

Comment 8

[josef radinger]

if i set somebody in the standard-cc-list (in the dropdown) it works as expected.
applied a patch against 3.4.5 which seems to fix the problem for me.

Comment 9

[josef radinger]

Attachment: check if initialcc is defined before using it

Comment 10

[josef radinger]

should i update the version if i have this in 3.4.5, too?

Comment 11

[Max Kanat-Alexander]

(In reply to comment #10)
> should i update the version if i have this in 3.4.5, too?

  No, the version field should reflect the earliest affected version.

Comment 12

[Xiao Wang]

What result? It happens after I new a product then want to create component for the product. I searched Google the whole day find no exact answer. It is confusing... Can I have your resolution? My email address is : [e-mail]. Many thanks.

Comment 13

[Frédéric Buclin]

Comment on attachment 432766 [details] [diff] [review]
check if initialcc is defined before using it

>-    my @initial_cc         = $cgi->param('initialcc');
>+    my @initial_cc;
>+
>+    if (defined $cgi->param('initialcc')) {
>+	@initial_cc         = $cgi->param('initialcc');
>+    }

I don't see how this could be correct. This change has no effect. That's not the problem with trick_taint().

Comment 14

[Steve]

To fix all errors with CC, in Adding new and editing cc's (removal and adding).

Fix is as follows.

bugzilla/components.pm

Old code...

sub _check_cc_list {
    my ($invocant, $cc_list) = @_;

    my %cc_ids;
    foreach my $cc (@$cc_list) {
        my $id = login_to_id($cc, THROW_ERROR);
        $cc_ids{$id} = 1;
    }
    return [keys %cc_ids];
}

New Code...

sub _check_cc_list {
    my ($invocant, $cc_list) = @_;

    my %cc_ids;
    foreach my $cc (@$cc_list) {
        if($cc){
           my $id = login_to_id($cc, THROW_ERROR);
           $cc_ids{$id} = 1;}
    }
    return [keys %cc_ids];
}

Comment 15

[Steve]

Attachment: Component.pm fix for empty CC errors on IIS/Windows systems

Comment 16

[Max Kanat-Alexander]

Okay, but there's an important question here--*why* is it getting undef?

Comment 17

[Frédéric Buclin]

Byron and I tested with IIS7, and we cannot reproduce the issue at all.

Comment 18

[Frédéric Buclin]

Comment on attachment 450951 [details] [diff] [review]
Component.pm fix for empty CC errors on IIS/Windows systems

If this error exists here, it will also exist at many other places, and what we should do in this case is to fix the root cause (which could be due to some bad config or an old version of IIS; I don't know).

Comment 19

[:glob ✱]

i can reproduce with IIS 5.1 (xp).

$cgi->param('initialcc') is returning an array with a single undef element.

Comment 20

[Max Kanat-Alexander]

  In that case, I'm somewhat tempted to just say that we don't support IIS on XP.

Comment 21

[Steve]

It also happens on 2K server. No idea on any newer as I've not bothered to setup an IIS on my new boxes. went Ubuntu instead.

Comment 22

[:glob ✱]

sorry, should have been clearer; right now i only have iis 5.1 and iis 7.5 to play with, so it's possible that this issue exists in more recent versions.

Comment 23

[:glob ✱]

what's going on here is in older IIS versions, if the QUERY_STRING is empty, they don't set the environmental variable.  recent versions set it to an empty string (i don't know exactly when this was fixed).

we override CGI::param() to check the QUERY_STRING if the requested variable wasn't in the POST'ed data, this calls SUPER::url_param().

as $ENV{QUERY_STRING} doesn't exist, url_param() is returning undef, which is returned as the value.

one fix would be to ensure QUERY_STRING is always defined, another would be to map undefs returned from url_param to empty strings.

Comment 24

[Max Kanat-Alexander]

  Hmm, we depend on the "defined $cgi->param" behavior in several places, so we don't want to map undefs to empty strings.

  I think checking for QUERY_STRING is a hack--how do we know that upstream url_param won't change in the future in some way to support some environment that doesn't have QUERY_STRING?

Comment 25

[:glob ✱]

(In reply to comment #24)
> I think checking for QUERY_STRING is a hack

agree, however working around upstream/server issues isn't exactly virgin territory for bugzilla.

> how do we know that upstream
> url_param won't change in the future in some way to support some environment
> that doesn't have QUERY_STRING?

if url_param is changed in that way, initialising QUERY_STRING won't affect it.

Comment 26

[:glob ✱]

Attachment: patch v1

here's the patch for ensuring $ENV{QUERY_STRING} is always defined.

Comment 27

[Max Kanat-Alexander]

Comment on attachment 457221 [details] [diff] [review]
patch v1

Beautiful!

Comment 28

[Frédéric Buclin]

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified Bugzilla/CGI.pm
Committed revision 7374.

Committing to: bzr+ssh://[e-mail]/bugzilla/4.0/
modified Bugzilla/CGI.pm
Committed revision 7329.

Committing to: bzr+ssh://[e-mail]/bugzilla/3.6/
modified Bugzilla/CGI.pm
Committed revision 7142.