From 4bbb07e8048ef859cfc29c6b9d221840f2c6aed1 Mon Sep 17 00:00:00 2001 From: "gerv%gerv.net" <> Date: Fri, 16 Jan 2004 06:34:12 +0000 Subject: Phase 1 of a big documentation update before 2.17.6. --- docs/html/extraconfig.html | 172 ++++++++++----------------------------------- 1 file changed, 37 insertions(+), 135 deletions(-) (limited to 'docs/html/extraconfig.html') diff --git a/docs/html/extraconfig.html b/docs/html/extraconfig.html index ff8540d10..ea07c01c7 100644 --- a/docs/html/extraconfig.html +++ b/docs/html/extraconfig.html @@ -4,16 +4,18 @@ >Optional Additional Configuration
As well as the text-based dependency graphs, Bugzilla also supports dependency graphing, using a package called 'dot'. @@ -144,9 +147,9 @@ CLASS="section" >
As long as you installed the GD and Graph::Base Perl modules you might as well turn on the nifty Bugzilla bug reporting graphs.
By now you have a fully functional Bugzilla, but what good are bugs if they're not annoying? To help make those bugs more annoying you @@ -294,47 +297,11 @@ CLASS="section" >4.2.4. LDAP Authentication
4.3.4. LDAP Authentication LDAP authentication has been rewritten for the 2.18 release of - Bugzilla. It no longer requires the Mozilla::LDAP module and now uses - Net::LDAP instead. This rewrite was part of a larger landing that - allowed for additional authentication schemes to be easily added - (bug - 180642). - This patch originally landed in 21-Mar-2003 and was included - in the 2.17.4 development release. - |
The existing authentication scheme for Bugzilla uses email addresses as the primary user ID, and a @@ -544,26 +511,26 @@ CLASS="section" >4.2.5. Preventing untrusted Bugzilla content from executing malicious +>4.3.5. Preventing untrusted Bugzilla content from executing malicious Javascript code
It is possible for a Bugzilla to execute malicious Javascript - code. Due to internationalization concerns, we are unable to - incorporate the code changes necessary to fulfill the CERT advisory - requirements mentioned in +>It is possible for a Bugzilla attachment to contain malicious + Javascript + code, which would be executed in the domain of your Bugzilla, thereby + making it possible for the attacker to e.g. steal your login cookies. + Due to internationalization concerns, we are unable to + incorporate by default the code changes necessary to fulfill the CERT + advisory requirements mentioned in http://www.cert.org/tech_tips/malicious_code_mitigation.html/#3. - Making the change below will fix the problem if your installation is for - an English speaking audience. + If your installation is for an English speaking audience only, making the + change below will prevent this problem.
Telling Bugzilla to output a charset as part of the HTTP header is - much easier in version 2.18 and higher (including any cvs - pull after 4-May-2003 and development release after 2.17.5) than it was - in previous versions. Simply locate the following line in +>Simply locate the following line in Bugzilla/CGI.pm
# Make sure that we don't send any charset headers - $self->charset(''); +> $self->charset('');
# Send all data using the ISO-8859-1 charset - $self->charset('ISO-8859-1'); +> $self->charset('ISO-8859-1');
Using <meta> tags to set the charset is not - recommended, as there's a bug in Netscape 4.x which causes pages - marked up in this way to load twice. See - bug 126266 - for more information including progress toward making - bugzilla charset aware by default. - |
You should modify the <DirectoryIndex> parameter for - the Apache virtual host running your Bugzilla installation to - allow index.cgi as the index page for a - directory, as well as the usual index.html, - index.htm, and so forth.