Closed
Bug 280547
Opened 20 years ago
Closed 19 years ago
When clicking on a URL from the email client that has arguments, the authentication window is not presented and authorization fails
Categories
(SeaMonkey :: MailNews: Message Display, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: mark, Assigned: Bienvenu)
Details
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.
Comment 1•19 years ago
|
||
over to david. david, any idea who owns the mailnews part of the seamonkey suite?
Assignee: sspitzer → bienvenu
Assignee | ||
Comment 2•19 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..
Comment 3•19 years ago
|
||
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•19 years ago
|
||
I think this is a Seamonkey bug, so I think it's whatever happens in xpfe/communicator/contentAreaClick.js
Comment 5•19 years ago
|
||
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•19 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
Comment 7•19 years ago
|
||
Hmm.. ok. Then yes, this is likely tied to the docshell prompt changes that landed on branch as security fixes...
Updated•19 years ago
|
Version: unspecified → 1.7 Branch
Reporter | ||
Comment 8•19 years ago
|
||
This problem seems to have been resolved in version 1.7.6.
Comment 9•19 years ago
|
||
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
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•