[Edbrowse-dev] Disabling local echo for password fields

[Karl Dahlke <eklhad@comcast.net>]

[-- Attachment #1: Type: text/plain, Size: 6628 bytes --]

Sure - here are a few thoughts.

1. The concept is fine - the implementation is not trivial, technically, or in its user interface.

2. Since we have zero windows edbrowse users at the moment, I'm fine with saying the feature only works on unix / linux for now.
The Windows port is more a proof of concept.
Let's be honest, windows users aren't really interested in command line programs.
There are a couple other features that only work on unix, so ok.
But, in the interest of a windows implementation some day,
I'd prefer a function in stringfile.c that turns echo on and off, using termios of course, and maybe some day having a windows equivalent that is a stub for now.
You'll notice in that same file the getch() function which is an msdos function, and has a unix equivalent, to grab a single character no echo.
This is used in the mail client, for quick one letter commands to step through your mail; not used in other parts of edbrowse so you may not have run into it,
but that's kind of a model for tty io and portability.
Put your echo on and off function in there, under #ifdef windows etc.

3. Test for isInteractive in the echo on off function, and have them do nothing if not interactive.
That way we don't have to test for isInteractive every time we call the function; just call it at the appropriate times.
This flag is set for interactive use, and is done in a unix / windows portable way.

4. Finally, call this function, on and off, when grabbing the password for http 401 authentication - piece of cake.

5. The easiest, and perhaps the only practical way to print stars on top of a password field is to muck with the print line routine.
I can't really change the password text in the buffer, because I am constantly comparing these fields with their javascript counterparts.
In other words, if I put stars in the buffer, a syncup routine will eventually think you typed stars in the password field,
and update the javascript variable, and pretty soon you're sending stars to the website as your password.
So you can only muck with the print routine at buffers.c line 255.
When characters in that line belong to <input type=password> print out stars instead.
This is not easy to do right now.
Line 240 fetches the line with mode 1, which strips all the hidden tags out, just the printable version,
so by line 255 I have no idea what characters come from what html fields.
You would need some earlier software, fetch the line with mode -1,
that has all the codes in it, then step through and look for
InternalCodeChar number < password text >
then check tagList[number],
is its action TAGACT_INPUT and is its itype TAGACT_PASSWORD,
and if yes then overwrite the characters in the fetched line, the one that is fetched with mode 1, with stars.
You can do that because the line fetched with mode 1 is allocated, and you can muck with it.
The line fetched with mode -1 is raw from the buffer and you shouldn't change it.

6. That all seems doable except I treat PASSWORD just like TEXT.
In other words, itype has no indication of password, it just knows text.
This is suppose to be the major input type.
text, submit, reset, radio, dropdown list, etc.
I wanted to implement a minor input type, t->itype_minor,
that would hold the types in decorate.c line 339.
Thus we have some foundational changes to make first, right?
But these should be made anyways for other reasons, syntax checking on the input etc.
Input type email looks like an email address, number is a number, etc.
uchar itype_minor in eb.h line 528
set the itype_minor when the itype is set in decorate.c
Now ... if(itype_minor == INP_PASSWORD) then replace the characters in the field with stars.

7. Ok that was a lot of work, but none of it hard, just plod along plod plod plod.
We must realize what we have though.
If you write the buffer to a file, the password is plain text once again.
That's rare, but you need to know it would work that way,
and if you then print that file later on, your password is visible.
Perhaps less rare, the et command to edit the page as pure text.
Sometimes I do this if I just want to muck with the text and not interact with the links any more.
At that point the html tags are gone and the password shows up in plain text.

8. Now for input i2=password, which I have no way to anticipate until you have already typed it in with echo.
A private command was suggested, and I'm ok with that, but would probably call it private rather than pi,
cause it's used so rarely I don't mind it having more than 2 letters, and we're kinda running out of 2 letter commands,
and they're rather cryptic anyways.
Sometimes I'm tempted to turn a few more rarely used 2 letter commands into more meaningful words, but we have to be careful changing a preexisting user interface, no matter how clunky it is.
Maybe priv, or noecho, we can discuss the actual command later.
It would set a flag and disable echo.
buffers.c line 385 inputLine() would get the line as usual, but turn echo on after it got the line.
A one time silent read.
Question - how would this work in readline mode, when I'm calling readline() rather than fgets()?
I don't know anything about readline; never use it.

9. The noecho command should probably print "echo off" or some such so you know you're ok to enter your password.
This should be an international message of course.
There are a lot of old messages we don't use any more, and they have been replaced with 0, so use one of those slots before you make additional entries to the file.
Example lang/msg-en line 508
Put the new English message there, and MSG_EchoOff in messages.h line 608, and we use that, and my friends translate as time permits.
We do have some international users, so this is worth the bother.

10. I greatly appreciate any help you can give. This project should have 50 fulltime programmers; it has 4 part time volunteers, who all have busy lives.
Don't get discouraged if I redirect you in some way; we could really use your help.

11. Any of these changes should be documented in the users guide, and I'm happy to do that.
It's written in raw html and not many people want to muck with that.
This is of course the last step, but an important one; and also mention the new feature(s) in CHANGES.

12. I can't comment on the curl ssl authentication discussion, I'm not sure why the change was made, or if it was getting around a bug in an old version of curl, a bug that isn't there any more,
or what we should really do here; I'll leave that to Chris and Adam.

Cheers,

Karl Dahlke