I run Kite over cloud on an AWS machine. For logins, I set the access_code over a local machine in the morning and seed my cloud machine with that access_code.
Today, I am able to set the access_code but when I use it over my cloud machine, I get captcha error.
Captcha is fine, but how do I solve it over a cloud machine because I dont get it when I use the same access_code over my local dev machine.
@ymograi Thanks. In my opinion it won't matter where the access_token is generated as the login process and subsequent requests all hit the same 'kite.trade' url. On easy solution is that I change the ip of my machine and hope that it doesn't face the captcha issue. This should usually work.
While one can do that there are two issues:
a. Cloud providers generally provide ip dynamically and there is very high likelihood that my cloud machine will be reassigned the 'bad' ip again. Today after four days, my ip was caught again for captcha. I don't know whether it is a new ip which got caught or the old 'bad' ip which was reassigned again. Both of these possibilities are big problems.
b. The more important issue is that the captcha shouldn't be there. Assuming, one uses a static ip which works fine. What may happen is that one has logged in and is running a few positions. For all api interactions with kite.trade one keeps hitting the kite.trade url. Suddenly Zerodha's system decides that these requests are originating from a bot and asks for captcha "in the middle of a trading session". Once a machine is caught, that point on, all requests from that machine will be rejected for that ip. Even if one is alert and watching while it happens, one will have to atleast reboot his machine.
And this can happen to any machine, even one running on your laptop at home. Cloud machines are higher risk as they are actually running trading bots and they come from high risk sources, i.e. cloud and their requests to kite.trade would possess corresponding signatures.
While (a) part of the problem is solvable but (b) can suddenly wreck the trading session and is "open". Thats what is worrying me. I dont want to trade with such high uncertainties.
I don't know why there is no response from zerodha.
1) Run the login in the cloud server. If GUI is not allowed, you can use text-only browser in the terminal window and generate the access_code.
2) Make sure that your https SSL certificate is in good order. Otherwise the redirect URL may not work properly and the spam protection layer at zerodha may pop up captcha at arbitrary times.
While one can do that there are two issues:
a. Cloud providers generally provide ip dynamically and there is very high likelihood that my cloud machine will be reassigned the 'bad' ip again. Today after four days, my ip was caught again for captcha. I don't know whether it is a new ip which got caught or the old 'bad' ip which was reassigned again. Both of these possibilities are big problems.
b. The more important issue is that the captcha shouldn't be there. Assuming, one uses a static ip which works fine. What may happen is that one has logged in and is running a few positions. For all api interactions with kite.trade one keeps hitting the kite.trade url. Suddenly Zerodha's system decides that these requests are originating from a bot and asks for captcha "in the middle of a trading session". Once a machine is caught, that point on, all requests from that machine will be rejected for that ip. Even if one is alert and watching while it happens, one will have to atleast reboot his machine.
And this can happen to any machine, even one running on your laptop at home. Cloud machines are higher risk as they are actually running trading bots and they come from high risk sources, i.e. cloud and their requests to kite.trade would possess corresponding signatures.
While (a) part of the problem is solvable but (b) can suddenly wreck the trading session and is "open". Thats what is worrying me. I dont want to trade with such high uncertainties.
I don't know why there is no response from zerodha.
1) Run the login in the cloud server. If GUI is not allowed, you can use text-only browser in the terminal window and generate the access_code.
2) Make sure that your https SSL certificate is in good order. Otherwise the redirect URL may not work properly and the spam protection layer at zerodha may pop up captcha at arbitrary times.
I think it is because of the bad IP. I would suggest checking the IP reputation.
I would suggest going for a static IP with good reputation.