Re: [gdm-list] Separate username and password fields

[Bob Doolittle <Bob Doolittle oracle com>]

Ludwig Nussel wrote:
> Brian Cameron wrote:
>   
> > > I've never liked that GDM only shows one field. I have on occasion
> > > started to type my username in only to then notice it's coming up in
> > > dots because the prompt to the side actually reads Password, but my
> > > research indicates that there is no way to configure to GDM to display
> > > separate fields for username and password. Which is a shame. Given
> > > that having only one field can evidently cause confusion I'd like to
> > > ask the developers to consider adding a configuration option to
> > > display separate username and password fields. I feel that is much
> > > more user friendly than using a single field.
> > >       
> > This usability issue is raised from time-to-time.  Unfortunately, the
> > standard for handling authentication is PAM, and GDM also uses PAM.
> > While PAM makes it possible to integrate novel authentication mechanisms
> > (such as a fingerprint or SmartCard reader), its query/response protocol
> > does not support asking multiple questions at the same time.
> >     
> Actually PAM does support multiple prompts at once. You just need a
> module that actually asks for username and password in one
> conversation (such as pam_unix2). Years ago I even made proof of
> concept patch for GDM:
> http://mail.gnome.org/archives/gdm-list/2007-February/msg00024.html
> IIRC fixing the graphical greeter turned out to require too much
> effort back then so I gave up.
>   
I took a look at pam_unix2 version 1.30 from 
http://freshmeat.net/projects/pam_unix2/
Is that the version you are referring to? I took a quick look over it.
That module does not do anything unusual. It only prompts for a password.

However, like a typical PAM module, it first calls pam_get_user().
pam_get_user() is a PAM framework call that prompts for the username 
(i.e. calls the conv function) if PAM_USER is not already defined.
So ABICT this module, like most PAM modules, results in two calls to the 
PAM conversation function, not one (assuming that the username isn't 
known in advance, either from being set by the client or a previous PAM 
module on the stack).
Therefore, a GUI that wanted to display two labeled text-input fields at 
once could not operate correctly with this module, since it wouldn't 
know the label for the 2nd text-input field (the password prompt) at the 
time it had to draw the label for the first one (the username).
What one *could* do, is to leave room for two vertical input fields, and 
draw them incrementally during the dialog - i.e. initially just draw the 
first one when receiving the first prompt (for username), then after the 
user completes the input deselect that text-input field (because we have 
no way of "replaying" that PAM dialog after the fact unless the 
conversation is restarted, so the user shouldn't be allowed to re-enter 
the text we already processed without signaling us to start over). Then 
when a second prompt is received draw its label and text-input field 
directly beneath the first. In a general sense, one could imagine 
configuring the number of input fields to be handled from a single 
screen, so that the greeter could allocate the real-estate up-front and 
handle the dialog appropriately. If the greeter wound up getting more 
prompts than expected it would of course have to fall back to current 
behavior upon receiving the N+1st call to the conv function, or maybe 
just clear the GUI and start at the top again for that prompt. You'd 
probably want a "start over" button to restart the PAM dialog in case 
somebody types in the wrong username, which would also reset the GUI and 
just draw the top dialog again when the conv function was next called.
Another thing that one *could* do (although I don't recommend it) is to 
configure something that ignores the PAM prompts and simply displays two 
pre-determined labels and hopes to get no more than two calls to the 
conversation function. I don't know how it would "gracefully" (I 
hesitate to apply such a word to this hack :-) ) handle an unexpected 
third call, nor do I know how it could do any sort of validation that it 
is in fact receiving a username and password prompt for the first two 
calls. Localization would also be a challenge. This just seems like a 
bad idea in general, but it's the closest approach I can think of to 
what's being requested.
If there's another version of pam_unix2 out there and I'm looking at the 
wrong one, I apologize and would appreciate a pointer to source for the 
one you are referring to.
-Bob