Closed Bug 521416 Opened 11 years ago Closed 10 years ago

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

Categories

(Bugzilla :: Administration, task)

3.4.2
All
Windows XP
task
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 3.6

People

(Reporter: cdoucette, Assigned: glob)

References

Details

Attachments

(1 file, 2 obsolete files)

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.
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.
When I switched to Apache - it worked fine.
Updated summary to reflect webserver configuration that causes it (i.e. IIS).
Summary: Adding component causes: Undef to trick_taint → Adding component on IIS causes: Undef to trick_taint
Version: unspecified → 3.4.2
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
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
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.
Duplicate of this bug: 551398
Hardware: x86 → All
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.
should i update the version if i have this in 3.4.5, too?
(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.
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 : 19331779@qq.com. Many thanks.
Attachment #432766 - Flags: review?(mkanat)
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().
Attachment #432766 - Flags: review?(mkanat) → review-
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];
}
Attachment #450951 - Flags: review?(LpSolit)
Okay, but there's an important question here--*why* is it getting undef?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Byron and I tested with IIS7, and we cannot reproduce the issue at all.
Keywords: qawanted
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).
Attachment #450951 - Flags: review?(LpSolit) → review-
i can reproduce with IIS 5.1 (xp).

$cgi->param('initialcc') is returning an array with a single undef element.
  In that case, I'm somewhat tempted to just say that we don't support IIS on XP.
Severity: major → normal
Summary: Adding component on IIS causes: Undef to trick_taint → Adding component on IIS 5.1 causes: Undef to trick_taint
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.
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.
Summary: Adding component on IIS 5.1 causes: Undef to trick_taint → Adding component on IIS causes: Undef to trick_taint
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.
  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?
(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.
Attached patch patch v1Splinter Review
here's the patch for ensuring $ENV{QUERY_STRING} is always defined.
Assignee: administration → bugzilla
Attachment #432766 - Attachment is obsolete: true
Attachment #450951 - Attachment is obsolete: true
Attachment #457221 - Flags: review?(mkanat)
Comment on attachment 457221 [details] [diff] [review]
patch v1

Beautiful!
Attachment #457221 - Flags: review?(mkanat) → review+
Flags: approval4.0+
Flags: approval3.6+
Flags: approval+
Target Milestone: --- → Bugzilla 3.6
Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/
modified Bugzilla/CGI.pm
Committed revision 7374.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.0/
modified Bugzilla/CGI.pm
Committed revision 7329.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/3.6/
modified Bugzilla/CGI.pm
Committed revision 7142.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Summary: Adding component on IIS causes: Undef to trick_taint → Some web servers fail to set the QUERY_STRING parameter
Summary: Some web servers fail to set the QUERY_STRING parameter → Some web servers fail to set the QUERY_STRING parameter (causing undef errors on IIS)
Duplicate of this bug: 571817
You need to log in before you can comment on or make changes to this bug.