[email protected] wrote:
Paul B. Gallagher wrote:
[email protected] 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.
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.
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.
--
War doesn't determine who's right, just who's left.
--
Paul B. Gallagher
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
