If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

When clicking on a URL from the email client that has arguments, the authentication window is not presented and authorization fails

RESOLVED WORKSFORME

Status

SeaMonkey
MailNews: Message Display
--
major
RESOLVED WORKSFORME
13 years ago
13 years ago

People

(Reporter: Mark Tischler, Assigned: Bienvenu)

Tracking

1.7 Branch
x86
All

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040920
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217

From the email client ("Mail & Newsgroups"), clicking on a URL that lives on an
Apache web server (version 1.3.29 running on UNIX Solaris 8) and that has
arguments (e.g., http://<something>?2005.01.27.001) will not present the
authentication box (an .htaccess file exists and, thus, the user is presented
with a box that asks for his/her ID and password).  It goes directly to the
screen that one gets to when one doesn't authenticate successfully.  If one
clicks on a URL without arguments, the authentication box is presented.  Then
subsequent clicks on the same link with arguments will work, because
authentication is no longer necessary for this browser session.  Interestingly,
if, instead of clicking on a URL, one copies and pastes the URL into the
Navigator's location bar, the authentication box is presented.  This problem
only happens when clicking on a URL in the email client.  That is, it does not
happen when clicking on an identical URL in the Navigator.  This was not a
problem in Mozilla 1.7.3, but appeared in Mozilla 1.7.5.  Unfortunately, there
is no URL I can give you, as we are seeing this on our company's intranet, which
is behind a firewall.

Reproducible: Always

Steps to Reproduce:
1. Click on a link that has arguments and is in or below a directory with a
.htaccess file.
Actual Results:  
Authentication failed and no authentication box was presented.

Expected Results:  
Authentication box should have been presented.

Using multiple themes.  This happened on multiple computers -- two running
Windows 2000 Pro SP4, and one running Windows XP Pro SP2.
over to david.

david, any idea who owns the mailnews part of the seamonkey suite?
Assignee: sspitzer → bienvenu
(Assignee)

Comment 2

13 years ago
Cc'ing Boris, as a wild stab. This might be a uri loader issue, or some security
fix in 1.7.5 might have caused this..
There was a whole slew of fixes in the way dialogs of this sort are posed for
1.7.5, yes.  ccing Darin, since I think he has the best idea of what the state
of things is.

David, does mailnews treat URIs at all differently based on whether they have a
query?  I thought it just opened a browser window and passed the URI to it
instead of directly usng the URILoader... is that correct?
(Assignee)

Comment 4

13 years ago
I think this is a Seamonkey bug, so I think it's whatever happens in
xpfe/communicator/contentAreaClick.js
Er.. no, I recall that there was some special code in mailnews to pass off the
clicks to a browser earlier (landed by Seth, iirc), because URILoader would only
do it once the server response had been received.  That's probably the first
place to look.
(Assignee)

Comment 6

13 years ago
you're right:

http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/mailWindow.js#226

but eventually, I think we call openTopBrowserWith(url), which is in the
xpfe/communicator/contentAreaUtils.js
Hmm.. ok.  Then yes, this is likely tied to the docshell prompt changes that
landed on branch as security fixes...
Version: unspecified → 1.7 Branch
(Reporter)

Comment 8

13 years ago
This problem seems to have been resolved in version 1.7.6.
There were docshell changes between 1.7.5 and 1.7.6 plus a fair bit more:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_7_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-12-15&maxdate=2005-03-15&cvsroot=%2Fcvsroot

WFM per reporter.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.