Describe the bug
getUser() treats a response without auth_token and without a Location header as a redirect. An HTTP 200 response can therefore trigger six identical requests and end with:
Too many redirects - possible WAF or geo-restriction
No HTTP redirect is required to reproduce this error. This also blocks authenticated Client initialization when the default homepage response omits the token, even if the same cookies authenticate successfully on /chart/.
Reproduction without credentials or network access
From a checkout of main after installing dependencies, run:
node <<'JS'
const axios = require('axios');
const TradingView = require('./main');
const originalGet = axios.get;
let requests = 0;
axios.get = async () => {
requests += 1;
return { status: 200, data: '<html>No auth token in this page</html>', headers: {} };
};
TradingView.getUser('test_session', 'test_signature')
.catch((error) => console.log({ requests, error: error.message }))
.finally(() => { axios.get = originalGet; });
JSOn 5baea86c8c7e576f13464919c86c3b4c4b0ecf4c:
{ requests: 6, error: 'Too many redirects - possible WAF or geo-restriction' }
Expected: one request followed by the existing authentication error. Redirect handling should require a redirect status and a nonempty Location header.
Live observation
During local setup, authenticated requests using the same cookies produced:
| Page |
HTTP status |
Location header |
auth_token in HTML |
/ |
200 |
absent |
absent |
/chart/ |
200 |
absent |
present |
Using the chart page allowed account authentication and candle retrieval. A later check returned an auth token from both pages and upstream getUser() succeeded. The homepage behavior is therefore variable in these observations; this report does not claim that it always omits the token or establish why its response changed. The mocked reproduction above isolates the library bug independently of that variation.
Root cause and expected behavior
In src/miscRequests.js, headers.location !== location is true when the header is undefined. Passing that value recursively selects the default homepage URL again, until the redirect limit is reached.
A fix should:
- Fetch the chart bootstrap page by default and let
Client use the same default.
- Follow actual HTTP redirects only, resolving relative destinations against the current URL.
- Preserve the existing five-redirect limit and explicit location override.
- Stop immediately when a non-redirect response has no authentication token.
Environment
- Library:
@mathieuc/tradingview 3.5.2, upstream main at 5baea86c8c7e576f13464919c86c3b4c4b0ecf4c
- OS: Linux
- Node.js: v26.8.1
- Axios: 1.13.6
Additional context
#310 added the redirect limit; this reproduces a case where that limit is reached without any HTTP redirect. The receiver-binding changes in #320 address a separate problem.
I have a focused patch with credential-free HTTP/WebSocket regression tests. On upstream production code, 17 of the 26 cases fail; all 26 pass with the patch. A live authenticated chart check also returned five candles.
Describe the bug
getUser()treats a response withoutauth_tokenand without aLocationheader as a redirect. An HTTP 200 response can therefore trigger six identical requests and end with:No HTTP redirect is required to reproduce this error. This also blocks authenticated
Clientinitialization when the default homepage response omits the token, even if the same cookies authenticate successfully on/chart/.Reproduction without credentials or network access
From a checkout of
mainafter installing dependencies, run:On
5baea86c8c7e576f13464919c86c3b4c4b0ecf4c:Expected: one request followed by the existing authentication error. Redirect handling should require a redirect status and a nonempty
Locationheader.Live observation
During local setup, authenticated requests using the same cookies produced:
//chart/Using the chart page allowed account authentication and candle retrieval. A later check returned an auth token from both pages and upstream
getUser()succeeded. The homepage behavior is therefore variable in these observations; this report does not claim that it always omits the token or establish why its response changed. The mocked reproduction above isolates the library bug independently of that variation.Root cause and expected behavior
In
src/miscRequests.js,headers.location !== locationis true when the header isundefined. Passing that value recursively selects the default homepage URL again, until the redirect limit is reached.A fix should:
Clientuse the same default.Environment
@mathieuc/tradingview3.5.2, upstreammainat5baea86c8c7e576f13464919c86c3b4c4b0ecf4cAdditional context
#310 added the redirect limit; this reproduces a case where that limit is reached without any HTTP redirect. The receiver-binding changes in #320 address a separate problem.
I have a focused patch with credential-free HTTP/WebSocket regression tests. On upstream production code, 17 of the 26 cases fail; all 26 pass with the patch. A live authenticated chart check also returned five candles.