feat(macOS, Unix): 2fa confirmation messages on display banner

[davidsanchez222]

The display banner when you run IBC is fine, but I think it would benefit from adding some messages to let the user know where they are at in the 2FA process.

2fabanner.mp4

I created a tail process that starts at the end of the logfile and pipes new lines into a while loop. That while loop keeps reading every new line of the logfile until it finds the messages we are looking for:

to let the user know the 2FA succeeded:

"Second Factor Authentication; event=Closed" followed by "Downloading settings from server; event=Closed"
The reason it is not just "Second Factor Authentication; event=Closed" is because of an edge case where the user has to select the 2FA device and gets timed out on that window. "Second Factor Authentication; event=Closed" immediately followed by "Downloading settings from server; event=Closed" indicates a successful two factor authentication.

Logs for the edge case:

2025-06-04 17:31:17:865 IBC: detected dialog entitled: Second Factor Authentication; event=Closed 2025-06-04 17:31:19:366 IBC: detected dialog entitled: Second Factor Authentication; event=Closed 2025-06-04 17:31:20:914 IBC: detected dialog entitled: Second Factor Authentication; event=Closed 2025-06-04 17:31:27:702 IBC: detected frame entitled: Second Factor Authentication; event=Lost focus 2025-06-04 17:31:27:703 IBC: detected frame entitled: Second Factor Authentication; event=Deactivated IBC returned exit status 143 autorestart file not found TWS finished

Logs for a successful 2FA

2025-06-04 22:49:20:734 IBC: detected dialog entitled: Second Factor Authentication; event=Closed 2025-06-04 22:49:20:735 IBC: Duration since login: 6 seconds 2025-06-04 22:49:22:383 IBC: detected dialog entitled: Downloading settings from server; event=Closed 2025-06-04 22:49:29:737 IBC: detected frame entitled: U... Interactive Brokers; event=Opened 2025-06-04 22:49:29:737 IBC: Found TWS main window

to let the user know the main TWS window is running:

"Login has completed"

The original trap command is changed as well.

trap 'pkill -P $$' TERM INT

This makes sure that the tail processes get killed when the user does Ctrl-C. It also closes everything else afterwards so it is functionally the same as

trap 'kill -TERM $PID' TERM INT

The behavior is the same with both traps except for the trap 'pkill -P $$' TERM INT trap makes sure the tail process is killed.

[rlktradewright]

Thanks for your suggestion.

As it stands, I don't think it's very useful. If the user can see the banner window, then they can also instantly see when login is completed (whether or not 2FA is included). How does it help to have something else tell them the same thing?

However there is the germ of a useful idea here, and that is a mechanism that enables IBC to inject messages into the banner window. The tail command on Unix and the Powershell Get-Content command on Windows seem ideal for enabling this (I wasn't aware of either command before reading your post).

With such a mechanism, IBC could make the login process progress much more visible, because there are many siutations that your proposal just doesn't react to. For example, if the user fails to acknowledge the 2FA alert within the 3-minute timeout and ReloginAfterSecondFactorAuthenticationTimeout is set to 'yes' in config.ini, IBC will keep restarting the login process until the user does acknowledge it, and this can go on for hours or even days (not that that is a likely event). And during this process, your proposal would show nothing, whereas with what I'm suggesting IBC could output useful information such as 'Re-login will occur in 4 minutes 35 seconds': this sort of thing occurs because IBKR's login servers don't permit immediate relogin if login has failed several times consecutively: IBC monitors these situations and takes account of them. Although your proposal could be enhanced to check more log messages, it's likely to be less reliable than IBC reporting things to the banner window itself.

I'll leave it at that for now, to give you a chance to respond.

[davidsanchez222]

As it stands, I don't think it's very useful.

Here is my use case, at least:

I have IBC running in a tmux session on a remote server. It restarts at midnight on Sunday every week via a cronjob. There are multiple users that ssh to this server. We run Python scripts that connect to the TWS API to get market data. I have ReloginAfterSecondFactorAuthenticationTimeout set to 'no'.

If the person responsible for the 2FA misses it for some reason and doesn't tell the other users, the other users wouldn't know to say anything just by seeing the banner, because the banner doesn't display that information. Of course, they would find out once they get an error trying to connect to the TWS API. However, finding that out via an error in the Python script is tedious because there are a lot of scripts and sub-processes within each. It would be nice to know before running the scripts that the TWS API is ready.

To prevent this, I could:

1. Make a small Python script that solely connections to the TWS API to test the connection.
2. Set ReloginAfterSecondFactorAuthenticationTimeout to yes, but I don't want to keep receiving IBKR Mobile notifications in the case that I am not near my machine to check and verify that the notification is coming from an IBC login and not a bad actor (abundance of caution in case the account gets compromised)
3. Check the logs.

However, the easiest way to see if the TWS API is open for connections would be to: attach to the tmux session, view the banner, and deduce whether 2FA succeeded from there using the messages added in the PR.

That being said I think I might be misunderstanding something about the ReloginAfterSecondFactorAuthenticationTimeout setting and overall how the 2FA works, so if you don't think its useful I can just keep it in my own local version that is fine.

IBC could output useful information such as 'Re-login will occur in 4 minutes 35 seconds':

This is a good idea that can be useful.

IBC to inject messages into the banner window
The tail command on Unix...seem ideal for enabling this
log messages, it's likely to be less reliable than IBC reporting things to the banner window itself.

I'm confused on the wording. Do you think checking the logs using tail could be useful to implement the 'Re-login will occur..' messages? Or do you think IBC should directly send that info to the banner window? If the latter, how would that communication happen?

I'd be glad to help implement this feature.

[rlktradewright]

Thanks for explaining your use case.

We could debate what the users will see if the 2FA alert is missed, but it's not really relevant. What I'm proposing would give you everything your script enhancement gives you, plus a lot more, and also provides a general mechanism for IBC to communicate via messages to the banner window. Whether this capability will be useful in the future for other purposes than monitoring 2FA progress, who can say, but it has the potential to be useful.

What I envisage is adding an additional parameter to the IBC logging functions (or using overloads). This parameter indicates that the logged message is to appear in the banner window (as well as the logfile), and would result in some marker being added to the message text to indicate this. The displaybannerandlaunch script would use the tail (Unix) or Get-Content (Windows) command to intercept each message appended to the logfile, checking for the presence of this marker, and if present writing the message to the banner. The IBC code would be enhanced to add this parameter to relevant messages relating to 2FA progress. Some additional messages may be added, and some existing ones may be made more understandable for the end user.

I hope this clarifies things.

[davidsanchez222]

I see. What file/function contains the logic for the IBC logging functions? I tried looking through the project but couldn't find anything.

[rlktradewright]

The logging functions are in the Utils.java code module:

logError
logException
logRawToConsole
logToConsole

I've started implementing this, and it's basically working on Windows. My remaining problem is to determine the process id of the process that runs the Get-Content command so that I can end it when IBC shuts down.

Once that's working I'll modify your code as required, though I will first have to recreate my Ubuntu virtual machine, which got corrupted recently when trying to upgrade from 20.04 to 22.04 (I've never yet managed to have a successful version upgrade with Ubuntu - I think it doesn't like me, in much the same way as I don't like it!...).

I'll let you know when I've got something you can try.