Authentication Error

[Spedius]

I already mentioned it on your youtube channel, but I thought it might also be prudent to note it here:

In essence, even after authenticating the account at the user's end, the server does not accept the authentication request, so the library can not be used. The image attached shows the VSC terminal, as well as the associated command terminal and website confirmation of authentication.

You mentioned it was due to the order in which endpoints were called, and I'd love to learn more about what in particular is causing that problem.

Thank you!

[wuliwei9278]

Same here. even after authenticating the account at the user's end, the server does not accept the authentication request

I am using Mac and the localhost does not seem to recognize that I have authenticated my account although the browser says it is successful. I tried to use system python3 instead of conda python3; different java installations, but the problem persists.

[areed1192]

Alright, I think I fixed the issue. The problem was the logic I wrote for determining whether the session was valid or not. The endpoints can be very inconsistent with responses unless you call them in a very specific order.

Try out the modifications and let me know if it works on your guys' end.

[Spedius]

Hey Alex, thanks for the update! While trying to use the new library I encountered two issues:

1. The config parser module seems a bit ambiguous and even when I was able to access the values from the terminal (I read up on the syntax here, and made a config folder which holds config.ini) the program was unwilling to access the necessary username/password/etc. Some info on how you intend for us to store the configuration values would be much appreciated:

2. The second, and arguably more important issue is when attempting to run the file. I got around the config issue by just importing a config.py the old fashioned way, and when running test_client.py I encounter this strange result:

self.CLIENT_PORTAL_FOLDER = pathlib.Path.cwd().joinpath('clientportal.beta.gw').resolve() may be an invalid directory, but as you can see from the screenshot above, it exists in the folder and thus is causing me some confusion.

I'd like to finish by apologizing for bothering you with all these issues. I really appreciate the work you've done so far and I'm very excited to try out this library. If there is any other information you need from me don't hesitate to ask.

[areed1192]

Config

I modified the readme to include instructions on how to set up the config.ini file. There is also a sample file you can use, in the /resources folder. I also mentioned that it is optional and that if you want you can just store the variables in the script.

Clientportal Beta

Regarding this, I modified the file path so that it references __file__. The reason you were initially experiencing issue was you weren't in the interactive-broker-python-api folder. You were in the folder that contained that folder.

However, I can't always assume that people will be directly in the folder, in fact, when they install the library they definitely won't be. With that in mind, it was a change I was going to have to make so that hopefully will fix your issue.

I will also more than likely completely get rid of the config.ini setup process and just ask people to provide the info in the script themselves.

Let me know if these fix your issues.

[Spedius]

Hello Alex, thanks again for your help with the previous issues. When attempting to reinstall the library, I am worried that I am not uninstalling the old library correctly. When I cloned the new directory, the line pip install -e . yields the following exception:

This seems to be a machine-specific error and likely a gap in my own understanding of how libraries are stored on local files, but even after deleting the old folder the exception persists.

Thank you so much!

[Spedius]

UPDATE: The issue was fixed by finding the rogue egg-link: The installation worked fine after this. Thanks again, hopefully this will help others with this issue.

[Spedius]

With regard to the original authentication error, the program returns the following:

I will poke around a bit, but please let me know if there's a fix for this error. Thank you!

[5tomato]

@Spedius I think this might be the same issue I was having. Assuming you were able to login on localhost:5000, this error results from the base url being:

localhost:5000/v1/api

instead of:

localhost:5000/v1/portal

You would have to go in and edit the client file in the repository, it's in the make request function.

[Spedius]

Hello 5tomato, thank you for your reply.

I checked around in client.py and found the following:

It seems that the base url as it is constructed in the most recent build of the repository is /portal. Unless I misunderstood your post, I believe the program already constructs localhost:5000/v1/portal as the base url.

Thank you still!

[5tomato]

Sorry for the confusion. Change the r'portal/' to r'api/'. If that doesn't fix it, then it's a different error. Also, you can look in the logs folder of the clientportal to see exactly the base url for the authentication is.

[Spedius]

It works!

Thank you VERY much!

[areed1192]

Well, this is very odd, so are you both able to get a working version when you specify the /api path? I can't recreate the issue that you're both experiencing so it's hard to pinpoint why you're getting the behavior.

I'm guessing it has something to do with the authentication, but it's so weird that it doesn't take /portal in the path. I'll have to look more into this and see why that is.

Could you give me a little more background on what is going on when you receive the issue? For example, do you have Trade Workstation open? Are you logged in online or anything like that?

[Spedius]

@areed1192 I quickly pulled up VSC and attempted the standard log in procedure (no TWS, only login from the localhost link provided by the program into the terminal). In the following image you see two attempts to log in: the first with the /api/ base url and the second with /portal/. Annoyingly enough, using /api/ (which worked yesterday) provided a new error. I changed it back to /portal/ which you see lower in the screenshot and got the old error I was having

I am not logged in by any other means nor do I have any other IBKR software open. If you want to see me run the program in real time please feel free to reach out.

What an odd authentication process! Thanks (yet again) for your help.

EDIT: I switched it back to /api/ and got the program working again:

Suffice to say I am at a loss.

[5tomato]

@areed1192 When I run the server, I see that the version of the API is from April 4th 2020, whereas the one from your videos is from sometime in March. Could that have something to do it?

I have to say, I am not experienced at all with HTTP, or REST API's so this is a learning experience for me. When I look at the logs in the clientportal/logs folder they show the endpoint having /api instead of /portal all the time, so that is why I changed it to /api.

Update: Another thing I have noticed, not necessarily related to the base url, is that the process id saved in the json file is not the server process id, but the pid for the run.sh command and killing the run.sh command does not kill the server (at least on mac). Killing the server process id does kill the run.sh command though. Not sure if that's how it's supposed to be.

[human1996]

Hello! I´m wirting this message to see if anyone could help me with the authenticate error that appears on the picture that you can see below. It is very frustrating because I´ve been trying everything to solve this issue by myself but actually, there is no solution by the moment . (I dowloaded the last version that Alex upload but the error is not fixed at all)

[areed1192]

@human1996 The error your experiencing can be very erratic from what I can tell. The problem is it only seems to appear when you log in to a new session after canceling the old one a while back. For example, I only experience this issue once a day when I log in for the first time.

At this point, I'm not entirely sure how to fix it. My solution so far has been to let the error run through once and then do it again. I'm going to keep looking into it but I can't promise a fixed date at this point.

[human1996]

Hello! Thank very much for you rushly answer, I really apreciate it. Firstly, I made a Demo account at Interactive Brokers and I followed all the steps correctly as you said on your youtube videos. But, finally I couldn´t solve the problem that I already told you. Because of that I decided to make a new Demo account removing the old one. So, my question is: the data of the paper account and paper username that we write to create our file "config.ini" and the data that we have to introduce at this URL " https://localhost:5000/sso/Login?forwardTo=22&RL=1&ip2loc=on" are related or not? Because I realized that they are not. To sum up, the error that appears when I replay yes at this question "Would you like to make an authenticated request (Yes/No)?" is related to some issue in my older account that is not being fixed correctly? Perhaps, the authenticate error occurs because there is no union between the config.ini and the data that we introduce at the URL.. Sorry for the inconvenience and I hope to have an answer as soon as possible. Thank you.

[areed1192]

Alright, so I did more testing on the authentication process and I think I got it in a good spot where it should connect reliably. Here are some things I've noticed through this process.

1. Cookies seem to impact the login process, when I do it in incognito mode I get much more consistent results.
2. If the session didn't connect right the first time, then you need to kill the terminal and restart the client. You can't try to reconnect with the session open. I'll be adding a new component to the server_state which will state whether the previous session was authenticated. If it wasn't it'll disconnect the server and reopen it for you.

3. I added some unit testing for those of you who would like to explore it yourself.

   @human1996 The redirect URL is the one provided by Interactive Brokers, I used to use the old one but that seemed to have issues with it. After reaching out to Interactive Brokers they recommended I use that one.

From what I can tell, the authentication error seems to be related to the previous session. If for whatever reason that didn't close out correctly then it conflicts the authentication process. The weird thing is that it'll say you're not authenticated sometimes but you can clearly make requests.

The reality is this API seems to have a lot of bugs in it, so it's going to be a "one step at a time" process to identify the error, work on a solution, and then integrate.

[wuliwei9278]

This may not be directly related to this package? But has anyone tried the interactive broker websocket? It worked for me initially but now it failed. Couldn't figure out why.

[benjaminpolk]

Hello, 👋 I'm having an issue on Mac launching the authentication. subprocess.Popen is running "bin/run.sh" and "root/conf.yaml" separately, rather than applying the config file in the same request. I was able to replicate everything fine using the os.system library rather than the subprocess.Popen. However, I would rather use subprocess and I'm not sure how to launch the other terminal window with os.system. Any advise would be appreciated! Thanks.

[vepak]

Hello, 👋 I'm having an issue on Mac launching the authentication. subprocess.Popen is running "bin/run.sh" and "root/conf.yaml" separately, rather than applying the config file in the same request. I was able to replicate everything fine using the os.system library rather than the subprocess.Popen. However, I would rather use subprocess and I'm not sure how to launch the other terminal window with os.system. Any advise would be appreciated! Thanks.

yes, having same issue in Mac. @benjaminpolk did you find any solution? Thank you.

[vepak]

This is how I fixed the issue with Mac, I've placed the script in start_server.sh file

content of start_server.sh

cd "PATH OF clientportal.beta.gw"
"bin/run.sh" "root/conf.yaml"

in client.py

IB_WEB_API_PROC = ["open", "-F", "-a", "Terminal", './start_server.sh']
self.server_process = subprocess.Popen(
    args=IB_WEB_API_PROC,
    cwd="Path of start_server.sh script",
    shell=False,
).pid

[benjaminpolk]

This is how I fixed the issue with Mac, I've placed the script in start_server.sh file

content of start_server.sh

cd "PATH OF clientportal.beta.gw"
"bin/run.sh" "root/conf.yaml"

in client.py

IB_WEB_API_PROC = ["open", "-F", "-a", "Terminal", './start_server.sh']
self.server_process = subprocess.Popen(
    args=IB_WEB_API_PROC,
    cwd="Path of start_server.sh script",
    shell=False,
).pid

This makes complete sense, but not working for some reason. I'll keep trying. Thanks for this!

[areed1192]

Just wanted to update you all that I rewrote the authentication process for the library. In essence, we can't use the endpoints we want to during all hours. Some endpoints will only behave correctly during normal market hours. What I had to do is not check if you're authenticated but instead if you can actually make requests to different endpoints.

A person will show "not authenticated" but still able to make all the requests. Don't ask me why because I have no clue. The API is very inconsistent, it will work "better" during market hours, but not so good on weekends or evenings.

Here is the new version PyPI:

pip install interactive-broker-python-web-api==0.1.1

[Suryaobulareddy2932]

Hi,

I'm also facing the same issue. For your reference I'm attaching the screen shot

[areed1192]

Did you update the library? I haven't had any issues as of late with the authentication.

[Spedius]

After using the library for several weeks with no issues, this new error started popping up on Monday:

Is the 'target machine' in question at IBKR? Or is this an API side issue. Thanks!

[Pachedzhiev]

Hi @areed1192 , i have similar issue like @5tomato and @Spedius but it cant be resolved with their solution

I have also this error