I have an idea for this application... I created 2 identical fields. I placed field 2 exactly on top of field 1 and locked field 2. I put this script in field 2 (the top field)...
on mouseUp select line 1 of field 1 end mouseUp on mouseDown put empty into me put empty into field 1 end mouseDown Then I put this script on field 1... on keyDown put "*" after line 1 of field 2 pass keyDown end keyDown You can then lock everything down and a user would need a can opener to see the password... Jim on 1/21/04 9:26 AM, Rob Cozens wrote: >> Well, I ended up taking a different tack on the password field >> thing. Although the solutions given will work in most cases I >> decided to go the route of setting the foreground, background and >> hilite color of my password field to white then disallowing the >> "copy" function (Cmd-C, Ctrl-C) so that no one can select the >> entered text, copy it to the clipboard then paste it into something >> else in order to obtain the password. In the end this ended up >> being easier than trying to (1) figure out all the possible ways >> someone can "get" the password and (2) ensure that whatever someone >> does with the mouse or keyboard, the entered password is correct >> (i.e. what if they use the mouse to select some of the "dots" in the >> field and remove them ... it was just getting too complicated). > > Hi Brian, > > I got into this thread a little late, so forgive me if this has been > addressed. > > The general approach to passwords is via an ask password dialog box > instead of a field. The ask password command takes care of all the > details you are struggling with when trying to replicate a password > dialog in a field. > > As part of this approach, the password is never unencrypted: Sys > Admin creates a password via the ask password dialog, hides the > result in the application, and tells the user what keys to press when > responding to ask password. Password verification involves comparing > the user's response to ask password with the encrypted response > stored in the application. > > Note that the user input is never derived by unencrypting the ask > password response. > > So I ask: > > 1. Is it necessary that the password be entered in a field instead > of via the ask password dialog? > > 2. Is there a reason why you need to know what keys the user pressed > (eg: the user is entering "secure" data instead of a predefined > password)? > > If you answer both questions in the negative, I suggest you look at > ask password syntax. -- OYF is... Highly resourceful people working together. <http://www.OwnYourFuture-net.com> Own Your Future Consulting Services Limited, 1959 Upper Water Street, Suite 407, Halifax, Nova Scotia. B3J 3N2 Info Line: 902-823-2477, Phone: 902-823-2339. Fax: 902-823-2139 _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
