Feature #166
closedCancel support for long running PCSC commands
0%
Description
The GUI's ExecutionEngine executes actions, which are in most cases IFD or other SAL commands, in a Future.
As it turns out, at least the Smartcard IO's $Card#transmitControlCommand()$ function prevents thread control by blocking the close functionality. The result is that though the executing thread is cancelled, the PCSC command continues to run until a timeout occurs. Additionally even though cancel has been called, all code after the long running PCSC command is executed afterwards.
This problem must be solved in order to prevent false behaviour and possibly data leaks against the users will and strange behaviour by not continuing despite the cancel button has been pressed.
The main question is how to stop running PCSC commands in the Smartcard IO.
Related issues
Updated by Tobias Wich almost 12 years ago
- Connect a PACE capable terminal (standard reader)
- Start the richclient and trigger the activation for the nPA
- Walk through the dialogs until the PACE is performed with the terminal
- Break execution in the GUI, not in the Terminal
The terminal will then continue to display the PACE specific user consent. The process continues when a timeout occurs, the process is aborted on the terminal or the PACE protocol is performed successfully. In any case the thread will stop execution at its fork point, the ExecutionEngine.
Useful points for debug breakpoints areorg.openecard.ifd.scio.IFD#establishChannel() in the line after executing the control command.org.openecard.gui.executor.ExecutionEngine#process() in the line where the CancellationException is caught after the step action is executed.
Updated by Tobias Wich about 9 years ago
- Tracker changed from Bug to Feature
- Priority changed from High to Normal
Updated by Tobias Wich over 5 years ago
- Status changed from New to Closed
This should be handled correctly for a long time now.