Closed
Bug 228612
Opened 21 years ago
Closed 21 years ago
Abbreviate (shorten) long username/passwords in URL bar
Categories
(SeaMonkey :: Location Bar, enhancement)
SeaMonkey
Location Bar
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 157354
People
(Reporter: d_yerrick, Unassigned)
References
()
Details
Attachments
(1 file)
15.64 KB,
patch
|
dveditz
:
review-
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208
I've observed in bug 184074 that the common objection to emphasizing the
host name is that the user/pass could be long enough to push the host name
completely out of the URL bar, negating any effect, and the objection to
hiding it entirely (bug 122445) is that it breaks FTP links in e-mails
sent by web host. To solve this, show only the first 16 characters of the
user/pass in the URL bar until the user focuses it.
For example:
http://www.microsoft.co...@fraudsite.example/
would expand to
http://www.microsoft.com-windows-ie-patches-ie6-get.cgi-q668468@fraudsite.example/
on focus.
Reproducible: Always
Steps to Reproduce:
1. Resize the browser to a narrow width.
2. Visit the URL.
Actual Results:
User name pushes host name off the right side of the visible URL bar.
Expected Results:
User name is shortened, and host name becomes visible in URL bar,
emphasized if bug 184074 is implemented.
Reporter | ||
Comment 1•21 years ago
|
||
Oh, and it's not OS-specific either.
OS: Windows 2000 → All
Hardware: PC → All
Comment 2•21 years ago
|
||
Actually this is a good idea, I would suggest instead of 16 characters, we would
shorten after 8 or 10.
www.bank.ca
is 11 characters.
16 characters would not protect against www.paypal.com from showing up in the
url bar.
I know the goal of this bug is to avoid the hostname from being pushed. but it
would help with the spoofing bug#122445
Comment 3•21 years ago
|
||
I don't like the idea of URL bar changing when I focus it. If I wasn't aware of
this bug, I'd guess that some javascript hack was used to change the URL bar
before I entered it (that shouldn't be possible, but bugs and exploits do exist)
and I wouldn't trust the content I see.
I think that the best way is to drop user and password from URL bar. The
resulting addresses are still valid, the user only needs to re-enter username
and password to access the content. If the user isn't aware that some username
and password is required, then it's better not to directly access the resource
via URL bar, IMO.
Perhaps add a new menu item to URL bar context menu labeled "Copy link location
including username and password" or some shorter variant of that.
Comment 4•21 years ago
|
||
Discussed in bug 122445 (which is *not* about hiding the username/pw). Dup?
Reporter | ||
Comment 5•21 years ago
|
||
I see it more as a genus/species than as a duplicate. Now that I've read a
bit more, I see bug 122445 as a meta-bug that states a general problem, and
bug 184074 and this bug as possible solutions to the problem.
![]() |
||
Comment 6•21 years ago
|
||
> breaks FTP links in e-mails sent by web host
Details, please?
Depends on: 122445
Reporter | ||
Comment 7•21 years ago
|
||
User signs up for web hosting. Provider sends an e-mail:
From: web hosting provider
To: customer
Subject: yourhostedsite.tld is now active
You can configure your site here:
https://user:pass@yourhostedsite.tld/admin/
You can upload web pages here:
ftp://user:pass@yourhostedsite.tld/
.
![]() |
||
Comment 8•21 years ago
|
||
So? What exactly is broken there by us not showing the username/password to the
user in the url bar or status bar, as long as we still send it?
Reporter | ||
Comment 9•21 years ago
|
||
Unconditionally hiding the user/pass may break copying the URL out of the
URL bar. That's why I suggested showing it again on focus.
![]() |
||
Comment 10•21 years ago
|
||
We actually have bug reports that request not showing it in the URL bar at all,
no matter what, since it gets stored in session history and url bar history,
letting people just walk up and pretend to be you....
Comment 11•21 years ago
|
||
As far as I know the only thing broken by not showing the username and password
is the copying and pasting of urls with that information.
We can have an about:config variable which lets advanced users see the username
and password so they can have the copy/paste functionality.
That way no website is broken and no functionality is lost.
Comment 12•21 years ago
|
||
![]() |
||
Comment 13•21 years ago
|
||
Darin, what was that other bug? We really need to focus effort on this issue...
Comment 14•21 years ago
|
||
Boris, I think the bug you are refering to is Bug 232567.
Updated•21 years ago
|
Comment 16•21 years ago
|
||
Comment on attachment 143514 [details] [diff] [review]
removes display of username and password for http and https
r- for same reasons given in bug 122445 and bug 157354 where this same patch is
found.
Attachment #143514 -
Flags: review-
Comment 17•21 years ago
|
||
I don't think very many people like the "magic changing urlbar" aspect of the
original request, so this has turned into a duplicate of bug 157354
*** This bug has been marked as a duplicate of 157354 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Comment 18•21 years ago
|
||
V dupe.
The original bug morphed, so this duplicate fits the currently targeted problem.
Status: RESOLVED → VERIFIED
QA Contact: benc
Updated•17 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•