+- iPXE discussion forum (https://forum.ipxe.org)
+-- Forum: iPXE user forums (/forumdisplay.php?fid=1)
+--- Forum: General (/forumdisplay.php?fid=2)
+--- Thread: [MENU] Another action on Enter than timeout (/showthread.php?tid=7233)
[MENU] Another action on Enter than timeout - sebastian - 2014-03-10 11:39
I have this menu:
Code:
#!ipxe
:start
clear scancount
clear completeinput
set deftimeout 0
:continue
menu PLEASE SWIPE YOUR ACCESS CARD IN THE CARD READER
item cancel
item --key 0 0
item --key 1 1
item --key 2 2
item --key 3 3
item --key 4 4
item --key 5 5
item --key 6 6
item --key 7 7
item --key 8 8
item --key 9 9
choose --default cancel --timeout ${deftimeout} input && goto process || goto start
:process
iseq ${input} cancel && goto cancel || goto cproc
:cproc
set deftimeout 56
set scancount ${scancount}X
set completeinput ${completeinput}${input}
iseq ${scancount} XXXXXXXXXXX && goto start || goto continue
:cancel
iseq ${scancount} XXXXXXXXXX && goto step2 || goto start
:step2
chain http://www.myserver.com/cardlogin.cgi?accesscard=${completeinput}currently, it works pretty well. But I want to assign Another action if the user press ENTER, than if the timeout expires.
So if the user press ENTER, I want something different happen, than if the user Waits until timeout (56 milliseconds) expires.
All menu items have shortcuts so it does not matter if the user is unable to use the Arrow keys and select a item and press enter.
I tried with assigning --key 0x0a but didnt work.
(KEY_ENTER -> LF -> CTRL_J -> 0x0a)
(eg "item --key 0x0a done")
Is this possible to tie ENTER permanently to a menu item?
RE: [MENU] Another action on Enter than timeout - mcb30 - 2014-03-10 12:49
(2014-03-10 11:39)sebastian Wrote: currently, it works pretty well. But I want to assign Another action if the user press ENTER, than if the timeout expires.
So if the user press ENTER, I want something different happen, than if the user Waits until timeout (56 milliseconds) expires.
That would imply that Enter would do something other than choose the currently-selected menu item. That seems to break the principle of least surprise; as a user I would be very puzzled by an interface which allowed me to select an item but then ignored my selection.
What is the root motivation for wanting to do this? There may be a better way to solve the problem.
Michael
RE: [MENU] Another action on Enter than timeout - sebastian - 2014-03-10 13:19
I tought you were to find out that from the menu title :-)
But here comes:
I have a keyboard-type HID cardreader that outputs CARDNUMBER+ENTER (as if it were typed on keyboard) when a card is swiped through.
As a simple anti-hacking measure, I did make so each menu item has a shortcut corresponding to a digit, and then the first menu in a menu loop, does have unlimited time to begin, and then each subsuquent menu, then the user only have 56 milliseconds to make a selection.
When a card is swiped through, it will send the keypresses with a delay of 20ms between, so the card reader will be fast enough to type the card number, but a human typing on the keyboard, will be unable to type sufficently fast.
56 milliseconds was the minimum delay allowed by "CHOOSE" Before it did ignore the delay and allow unlimited time.
Currently, ENTER now checks if a cardnumber of exactly 10 digits has been entered, faster than 56 ms between each digit, else it restarts from the beginning.
If the user hammers on the keyboard and are lucky enough, he will enter exactly 10 digits by luck, and then the user does not need to press enter since 56 milliseconds implies ENTER.
Of course, it will be a random cardnumber, but he could hit a valid user by luck.
If I could separate the "Timeout" to actually execute Action A, and the "ENTER" to actually execute Action B, then I can code timeout to Always restart from the beginning, thus making it even harder since the user must, to hack the system, press 10 digits AND enter, with a maximum delay of 56 ms between keypresses.
A nice thing could be to add --timeoutaction [action], for example "--default done --timeoutaction cancel" would execute "done" menu item if user press ENTER without doing anything else, and execute the selected menu item, if the user selects a menu item and press ENTER, and would execute "cancel" if the user Waits the timeout.
This also would have use cases in other cases, for example if a system administrator want the user to press enter within 3 seconds to initiate recovery, OR select a menu item within 3 seconds to do Another thing OR simply wait 3 seconds to do a normal boot.
RE: [MENU] Another action on Enter than timeout - mcb30 - 2014-03-10 13:28
(2014-03-10 13:19)sebastian Wrote: If I could separate the "Timeout" to actually execute Action A, and the "ENTER" to actually execute Action B, then I can code timeout to Always restart from the beginning, thus making it even harder since the user must, to hack the system, press 10 digits AND enter, with a maximum delay of 56 ms between keypresses.
So, as I understand it, at the point you wish to test for Enter being pressed, the only key you care about is Enter.
If so, then you can use the http://ipxe.org/cmd/prompt command to check for Enter at this point, rather than creating a menu. You'd use a menu (with presumably no timeout) for the first digit, then menus with a 56ms timeout for the remaining nine digits, then a prompt with a timeout of 56ms to capture the final Enter.
Michael
RE: [MENU] Another action on Enter than timeout - sebastian - 2014-03-10 13:31
But I want to do a Another action if a "invalid" key is pressed (same as if timeout did exit). Does a invalid key prematurely exit the prompt timeout?
RE: [MENU] Another action on Enter than timeout - sebastian - 2014-03-17 13:59
Works perfectly now.
The script automatically "cancels" the timeout if a incorrect key is pressed, thus returning to start.
The system is as good as watertight now. Only the cardreader can input data into the login system now :-)
Here is the completed script:
Code:
#!ipxe
set servermessage Please swipe your card !
cpair --foreground 7 --background 0 0
cpair --foreground 7 --background 0 1
cpair --foreground 7 --background 0 2
cpair --foreground 7 --background 0 3
cpair --foreground 7 --background 0 4
cpair --foreground 7 --background 0 5
cpair --foreground 7 --background 0 6
cpair --foreground 7 --background 0 7
set lf:hex 0a
set lfs ${lf:string}${lf:string}${lf:string}
set lflong ${lfs}${lfs}${lfs}${lfs}${lfs}${lfs}${lfs}${lf:string}${lf:string}
set sp:hex 20
set ss ${sp:string}${sp:string}${sp:string}${sp:string}${sp:string}
set spaces ${ss}${ss}${ss}${ss}${ss}${sp:string}${sp:string}
:start
set scancount:int32 0
clear completeinput
set deftimeout 0
:continue
menu ${servermessage}
item --key 0 0
item --key 1 1
item --key 2 2
item --key 3 3
item --key 4 4
item --key 5 5
item --key 6 6
item --key 7 7
item --key 8 8
item --key 9 9
item
item
item
item
item
item
item
item
item
item cancel
choose --default cancel --timeout ${deftimeout} input && goto process || goto start
:process
iseq ${input} cancel && goto start || goto cproc
:cproc
set deftimeout 56
set servermessage Please swipe your card !
inc scancount
set completeinput ${completeinput}${input}
iseq ${scancount} 10 && goto doprompt || goto continue
:doprompt
prompt --key 0x0a --timeout 56 ${spaces}Please swipe your card !${lflong}${sp:string} && goto doecho || goto start
:doecho
chain http://192.168.1.2/boot.cgi?${completeinput}The "set servermessage" line is actually printed by a perl script, so it can for example show the user "Invalid access card, try again" or "This access card is barred, please call IT dep!"
RE: [MENU] Another action on Enter than timeout - mcb30 - 2014-03-17 16:21
(2014-03-17 13:59)sebastian Wrote: Works perfectly now.
The script automatically "cancels" the timeout if a incorrect key is pressed, thus returning to start.
The system is as good as watertight now. Only the cardreader can input data into the login system now :-)
Nice.
I'm impressed.Michael
RE: [MENU] Another action on Enter than timeout - sebastian - 2014-03-17 20:00
This also works perfectly with other types of things that use HID as interface (If you use my code - change the code to include the chars and digits your login system uses by adding/removing/editing menu items)
So anyone here can in fact use this to build a very secure iPXE login system.
(Combining this with for example Yubikey would make this extremely secure since you actually need a yubikey - you cant write down a YK OTP and then enter it later on keyboard)
Example:
Yubikey tokens (use following menu items: c b d e f g h i j k l n r t u v) (Replace "iseq ${scancount} 10" with "iseq ${scancount} 44").
Barcode readers (use chars and numbers that match your barcode "tickets" - note that the menu can only offer 19 different characters so create your barcodes with care).
(Another idea is to use such a menu Before and after a "login", making barcode "prepend" a static string to barcode, and "append" a static string to end of barcode and system will only accept a login if the prepend and append is correct ensuring no one enters a barcode manually - this makes so you can use any chars in a barcode)
Using RS232 to USB keyboard HID adapters (Example) to automatically login a computer from a door access Control system when a office front door is opened.
Control iPXE from external Equipment.
EM4100/EM4102/Mifare Readers.
Wiegand cardreaders or magnetic cardreaders with HID output.
and much more. The possibilites are endless, since the server that serves iPXE can react in many different ways too - for example the server can in turn remotely Control Equipment in reaction to iPXE events.