On 19/03/2016 8:21 AM, mozilla-lists.mbou...@spamgourmet.com wrote:
Paul B. Gallagher wrote:
mozilla-lists.mbou...@spamgourmet.com wrote:
Paul B. Gallagher wrote:
mozilla-lists.mbou...@spamgourmet.com wrote:
All this means that, as David mentioned, the password manager has no
way to know that the password requested on the second page is in any
way related to the username requested on the first page. It may be
obvious to you that you're being asked for a username and password.
It may be possible to do something that tries to work it out, but it
probably wouldn't be completely reliable (and then people would
probably complain about the odd time it doesn't get it right). Even
determining that a given field is for a username, and not a search
term or some other bit of information, is not necessarily easy.
Logically, it should be possible. Suppose the password manager has a
record with
domain <whatever.com>
login "YourName"
password "StealMe"
When the user visits a page in <whatever.com> that contains a "login"
field, it should know to enter "YourName." When the user clicks and is
taken to another page in <whatever.com> that contains a "password"
field, it should know to enter "StealMe."
So if the first page has a username field for logging in and a search
box (e.g. as part of a standard page header), how does it know which one
to put the username in? Because it's labelled something like "username"
or "log in" or "ID"? What happens with a page with some unexpected term
to label the username field, or where the human-readable label is an
image and the field name on the form is something like "field01"? It
wouldn't detect that it's a username field, so wouldn't fill in the
username. That's the "not completely reliable" part when users would end
up complaining it doesn't work. It's also the kind of thing a web
developer determined to prevent it from working for their site could
take advantage of.
It would know which box to fill in the same way that it knows which box
to fill when both are present -- if you look at the source code for the
page, each box is tagged with a name. When SeaMonkey first saves the
username and password data for a domain, it puts the username in the
"Username" field of its database and the password in the "Password"
field of its database.
That's in the password manager's database, but I'm talking about how it
knows which field on the web page is which.
Here's an example of source code from a form I sometimes log into:
<form id="loginForm" name="loginForm" method="post" action="/">
<div class="q-form-element">
<label for="u">Username</label>
<input id="u" name="u" placeholder="Username" required
autocomplete="off" value="" type="text"></div>
<div class="q-form-element">
<label for="p">Password</label>
<input id="p" name="p" placeholder="Password" required
autocomplete="off" type="password" value=""></div>
<div class="q-form-buttons">
<span><input type="submit" class="q-button qModeButton "
name="qMode-login" value="Login"></span>
In this case, the webmaster has used the name "u" for the username and
"p" for the password. SeaMonkey has never had any trouble understanding
that and placing the correct data in the correct fields. Or perhaps SM
is noticing the placeholders "Username" and "Password." Either way, it
works.
How does it know that the field named "u" is the username? I think I
recall seeing somewhere (and
<https://blog.mozilla.org/dolske/2013/08/20/on-firefoxs-password-manager/>
backs this up) that:
- It finds the password field (it has type="password" to mask the
password, so it's fairly obvious).
- It assumes the username field is just before that.
(Having read that, it does seem that someone determined to prevent
Mozilla's password manager from working on their site could do so quite
easily anyway, so perhaps my comments about attempts to deliberately
break it aren't so relevant).
If the password field isn't on the same page, it can't find the username
field. If there is, for example, a search form on the same page, there
may even be two forms, each with one text box. e.g. something like:
<form id="form1" name="form1" method="post" action="/">
<label for="field1">Name</label>
<input id="field1" name="field1" required type="text">
<input type="submit" name="submit1" value="submit1">
</form>
<form id="form2" name="form2" method="post" action="/">
<label for="field2">Email</label>
<input id="field2" name="field2" required type="text">
<input type="submit" name="submit2" value="submit2">
</form>
Which one is the username part of the login? You as a human might be
able to work out from the layout of the page etc. that the "Name" field
is for searching for people (perhaps this is a social network site)
while the "Email" field is used as the username for logging in. There's
no requirement to name and label the fields in any particular way, so
any attempt would be even more guesswork than the current system.
I don't claim that password managers are designed that way. But
logically it should be possible. It's like going to 411.com and
asking for a person's phone number on one page and the same
person's street address on another page -- both pieces of data are
contained in the same record, and the database returns one piece in
response to one input and the other piece in response to the other
input.
I don't see the relevance... Searching for someone by phone number
or address are two different queries. You might not even be looking
for the same person in the second query on address as you were
looking for in the first query on phone number.
Read again:
both pieces of data are contained in the same record, and the
database returns one piece in response to one input and the other
piece in response to the other input.
In the same way, a password manager could return one piece (the
username) in response to one input (the first page that requests the
username) and the other piece (the password) in response to the other
input (the second page that requests the password), drawing both from
the same record (its record for the domain in question). Any page in
<whatever.com> should prompt the PM to access the same record, and
return the username or password as appropriate.
Ah right; I think we were talking cross-purposes. You meant the fields
in the password manager's internal database, while I meant the fields of
the login form on a web page (and, assuming you were talking about the
same thing, thought you comparing a directory web site with separate
pages for searching by phone number or address).
Mark, does it really matter??
When you went to a certain website, that website required you enter two
bits of data. You enter two bits of data, which SeaMonkey stores under
what it calls "User Name" and "Password". You do your business and you
leave.
The nest time you go to that website, it requires two bits of
information and SeaMonkey thinks "Hey, I've got two bits of information
for this website ... Here you go."
Every bodies happy!
--
Daniel
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101
Firefox/42.0 SeaMonkey/2.39 Build identifier: 20151028234211
or
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101
SeaMonkey/2.38 Build identifier: 20150903203501
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey
