Closed Bug 337258 Opened 19 years ago Closed 19 years ago

Sudo session started page is messed up

Categories

(Bugzilla :: User Interface, defect)

2.22
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: gdsotirov, Unassigned)

Details

Attachments

(2 files)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; bg; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; bg; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 The 'Sudo session started' page looks doubled and moreover there is a HTTP header line for a cookie in it Reproducible: Always Steps to Reproduce: 1. From the Bugzilla Home page navigate to Edit -> Prefs -> Permissions; 2. Then click on the 'impersonate someone else' link; 3. Follow the instructions of the 'Begin sudo session' page and after filling the fields push the 'Begin session' button. Actual Results: The page that appears is not presented well. It is doubled and there is a HTTP cookie header visible in it. See the attached screenshoot. Expected Results: The HTTP header shouldn't be visible and the pages shouldn't be doubled. The screenshoot was made on a installation which was checked out from CVS like this, because the update from 2.18.5 failed: $ export CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot $ cvs login (Logging in to anonymous@cvs-mirror.mozilla.org) CVS password: anonymous $ cvs checkout -rBUGZILLA-2_22
This is a screenshoot of the 'Sudo session stared' page with the described problems.
karl, can you reproduce? I don't remember we had such problems when implementing this feature.
(In reply to comment #3) > related to Bug 325579? > I don't think so, but who knows. I had this problem once with 2.20, but it was because of a personal modification done in this template. This problem doesn' exists in my current 2.22 installation.
Until waiting this bug to be confirmed I've done some investigation. The relogin.cgi has the following line [http://lxr.mozilla.org/bugzilla/source/relogin.cgi#211]: 211: print $cgi->header(); And after this the line [http://lxr.mozilla.org/bugzilla/source/relogin.cgi#212]: 212: $template->process($target, $vars) For the current case the $target variable being 'global/message.html.tmpl'. So I've checked the template and I can clearly see that it invokes header processing also [http://lxr.mozilla.org/bugzilla/source/template/en/default/global/message.html.tmpl#31]: 31: [% PROCESS global/header.html.tmpl %] I'm unsure what exactly should be done, since I don't know Bugzilla code well, but I suppose that the header processing in relogin.cgi should be removed. Any suggestions?
Version: unspecified → 2.22
I definitely cannot reproduce the bug. And $cgi->header() and [% PROCESS global/header.html.tmpl %] are two distinct things. Both are required. You should try to clear your cookies and reload the pages (maybe are they stored in your cache and it still has an old CSS). So I would tend to mark this bug as WFM.
(In reply to comment #6) > I definitely cannot reproduce the bug. And $cgi->header() and [% PROCESS > global/header.html.tmpl %] are two distinct things. Both are required. You Yes. I had time this afternoon to look at the code. They are different. > should try to clear your cookies and reload the pages (maybe are they stored in > your cache and it still has an old CSS). So I would tend to mark this bug as > WFM. > I've cleared all my personal data in Firefox. No change. I'm attaching now the gnerated source. Maybe it will help to distinguish the problem. Maybe this is a problem of my installation only and I'll take time to investigate it this weekend.
Set-Cookie: Bugzilla_login=1; path=/ Set-Cooki​​​​​e: Bugzilla_logincookie=ImpzzQO3hj; path=/ Set-Cookie: sudo=2; path=/; expires=Thu, 11-May-2006 01:30:38 GMT Date: Wed, 10 May 2006 19:30:39 GMT Content-Type: text/html; charset=​​​​​UTF-8 This is from your attachment. This has nothing to do here. Could you paste the output of: ./checksetup.pl --check-modules
(In reply to comment #9) > This is from your attachment. This has nothing to do here. From my attachment!? It is in the generated source... > Could you paste the output of: > ./checksetup.pl --check-modules Here it is: # ./checksetup.pl --check-modules Checking perl modules ... Checking for AppConfig (v1.52) ok: found v1.56 Checking for CGI (v2.93) ok: found v3.17 Checking for Data::Dumper (any) ok: found v2.121_08 Checking for Date::Format (v2.21) ok: found v2.22 Checking for DBI (v1.38) ok: found v1.50 Checking for File::Spec (v0.84) ok: found v3.16 Checking for File::Temp (any) ok: found v0.16 Checking for Template (v2.08) ok: found v2.14 Checking for Text::Wrap (v2001.0131) ok: found v2005.082401 Checking for Mail::Mailer (v1.67) ok: found v1.73 Checking for MIME::Base64 (v3.01) ok: found v3.07 Checking for MIME::Parser (v5.406) ok: found v5.420 Checking for Storable (any) ok: found v2.15 The following Perl modules are optional: Checking for GD (v1.20) ok: found v2.31 Checking for Chart::Base (v1.0) ok: found v2.3 Checking for XML::Twig (any) ok: found v3.23 Checking for GD::Graph (any) ok: found v1.4307 Checking for GD::Text::Align (any) ok: found v1.18 Checking for PatchReader (v0.9.4) ok: found v0.9.5 Checking for Image::Magick (any) ok: found v6.2.7
No sign of the problem now. May be it was because of previously stored data (cookies, cache, etc) as Frédéric Buclin suggested in comment #6.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
And I've just remembered that recently I do TRUNCATE TABLE logincookies in the bugs database. This is because I read in the release notes of Bugzilla 2.22 [http://www.bugzilla.org/releases/2.22/release-notes.html], that for security reasons it is good to execute the command after upgrade to 2.22. I'm not sure that there is connection between the problem and this table data, but even I've cleared my personal data in Firefox several times the problem presisted until now.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: