port (:80) is added to the Site entry in the password manager when using web server auth




18 years ago
17 years ago


(Reporter: bugzilla, Assigned: badami)


Windows 2000

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [patch needs r/sr=])


(1 attachment)



18 years ago
I have some sites that uses web server auth (via .htaccess) files. When I ask 
Mozilla to save the username/password for these logins a portnumber is adding 
to the site entry in the Password Manager.
Fx if I log into http://dev.gemal.dk and let Mozilla remember the 
username/password the Site entry in the Password Manager gets listed as 
dev.gemal.dk:80 (Development)

The ":80" should *not* be added!

build 20010814

Comment 1

18 years ago
This sounds similar to bug 84776.  Probably need a patch similar to that one to 
fix this problem.

Comment 2

18 years ago
That site name is not being generated by password manager but rather is 
being passed to it from http authentication.  Below is the stack showing this.  

SINGSIGN_PromptUsernameAndPassword(const unsigned short * 0x00000000, const 
unsigned short * 0x05beb3a0, unsigned short * * 0x05beb32c, unsigned short * * 
0x05beb36c, const char * 0x0012f4a0, nsIPrompt * 0x05bf35b0, int * 0x0012f7dc, 
unsigned int 2) line 2361 + 47 bytes
nsSingleSignOnPrompt::PromptUsernameAndPassword(nsSingleSignOnPrompt * const 
0x05bf34a0, const unsigned short * 0x00000000, const unsigned short * 
0x05beb3a0, const unsigned short * 0x0012f550, unsigned int 2, unsigned short * 
* 0x05beb32c, unsigned short * * 0x05beb36c, int * 0x0012f7dc) line 581 + 51 
nsHttpChannel::PromptForUserPass(const char * 0x05bdbfe0, int 80, int 0, const 
char * 0x0012f9b0, nsAString & {...}, nsAString & {...}) line 1489 + 162 bytes
nsHttpChannel::GetCredentials(const char * 0x05bea870, int 0, nsAFlatCString & 
{...}) line 1285 + 53 bytes
nsHttpChannel::ProcessAuthentication(unsigned int 401) line 1157 + 23 bytes
nsHttpChannel::ProcessResponse() line 431 + 12 bytes
nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x05bd81c4, nsIRequest * 
0x05be2490, nsISupports * 0x00000000) line 2174 + 11 bytes
nsOnStartRequestEvent::HandleEvent() line 110 + 53 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x05bea4c4) line 65
PL_HandleEvent(PLEvent * 0x05bea4c4) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00aebeb0) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x002304a4, unsigned int 49295, unsigned int 0, 
long 11452080) line 1071 + 9 bytes
USER32! 77e71268()
Component: Password Manager → Networking: HTTP

Comment 3

18 years ago
Really reassigning this time.
Assignee: morse → neeti
QA Contact: tpreston → tever
darin could your prioritize?
Assignee: neeti → darin

Comment 5

17 years ago
why is it wrong to add :80 to the hostname in the password manager entries?  of
course we could leave it off since it is the default port and there wouldn't be
any ambiguity, but why is it wrong as it currently is?

Comment 6

17 years ago
henrik: can you please address comment #5.  i'm tempted to mark this WONTFIX.

Comment 7

17 years ago
I just think that if you dont have a port in the URL we shouldn't add a port. If
the user specify :80 it's ok to add a port.

It looks weird and confusing. Most common users have no clue about port 80. So
if thay check the entries they might wonder what the :80 means...

Comment 8

17 years ago
ok, from the UI point of view, ic your point.  thx for spelling it out for me!

-> badami
Assignee: darin → badami


17 years ago
Whiteboard: [patch needs r/sr=]


17 years ago
Keywords: patch

Comment 10

17 years ago
Comment on attachment 67641 [details] [diff] [review]
add port to domain string only if it was originally mentioned

Attachment #67641 - Flags: superreview+

Comment 11

17 years ago
Need a r= on this one.

Comment 12

17 years ago
Comment on attachment 67641 [details] [diff] [review]
add port to domain string only if it was originally mentioned

Looks fine to me
Attachment #67641 - Flags: approval+

Comment 13

17 years ago
Fixed with checkin
Checking in src/nsHttpChannel.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v  <--  nsHttpChann
new revision: 1.88; previous revision: 1.87
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 14

17 years ago
sure is fixed...

Comment 15

17 years ago
It is fixed, or this could be a new bug now :) Cause before, mozilla saves these
urls with port number, even if 80. So users, as me, have to edit their
SignonFileName, to add another copy of entries with :80 (or delete the ':80' :-)
)? Probably this not the right way:( Mozilla should recognize even if there is a
port number 80, if no port specified in uri. Probably there are many users who
use mozilla but don't know nothing about it, just they will recongnize in new
release that this is not working like before. :( 


Comment 16

17 years ago
The new nightly builds add the :80 too, once again. It works fine in release
0.9.9 but after this in new builds wont work as it works before :(.

Comment 17

17 years ago
this has now returned...
Resolution: FIXED → ---

Comment 18

17 years ago
this would still not appear on the UI which prompts for the username/password.
It will be stored in the password database file and hence appear in the password
This is intended behavior. In the password manager we always deal with the
cannonicalized versions of the host:port.

Marking as wontfix.
Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX

Comment 19

17 years ago
still dont get it.
why do it need to be in the "password database file"? Portnumbers are not added
to any other entries....

Comment 20

17 years ago
What about a 'SignonFileName fixer' program? 
Probably many users can't, or don't know how to fix this in SignonFileName. 
In xxx release works int one case, in another release worked in another case, in
mozilla 1.0 will work right in as worked in older releases .... Hm :( 
Why can not check: if there is no port number, it means that mozilla use it for
default :80, if there is port number in file, mozilla use it as in new builds.
Just an idea, cause I need to change every time my SignonFile too :-(
You need to log in before you can comment on or make changes to this bug.