marketcalls/openalgo

Summary After the configured daily session boundary (03:00 IST by default), OpenAlgo can continue sending quote and history requests with the previous trading session's broker credential. Broker-specific failures such as Zerodha's Incorrect api_key or access_token are then surfaced as repeated HTTP 500 errors and stack traces until an unrelated browser route finally runs session cleanup. This must be handled in shared authentication/service code so every daily-expiring broker gets the same behavior. Reported reproduction Authenticate a daily-expiring broker before 03:00 IST. Leave OpenAlgo, its WebSocket feed, and an API/dashboard client running across SESSION_EXPIRY_TIME. Continue calling quote or history endpoints after the boundary. Observe repeated broker credential errors. In the supplied Zerodha log, failures occurred from 06:09 IST, while OpenAlgo logged Session expired at 2026-08-22 03:00:00+05:30 IST and performed cache/pool teardown only at 06:10:37. Do not include the repo

Summary The multi-stage Dockerfile selects base images only by mutable tags. Evidence Dockerfile:2, Dockerfile:17, and Dockerfile:26 use tag-only image references. The stages use official Node and Python images but do not record immutable digests. Why this matters A mutable base tag can resolve to different content between builds, weakening reproducibility and supply-chain review. Digest pins make the exact base content explicit. Scope Pin every base image to a verified digest while retaining a readable tag. Confirm multi-stage aliases and supported architectures still build, and document the safe update procedure. Acceptance criteria All FROM references include tag@sha256:digest. Digests are taken from the official image registry/manifests. The production target builds for the project's supported architecture(s). A short comment or maintainer note explains how pins are refreshed. No credentials or registry tokens are committed. Verification rg -n "^FROM " Dockerfile docker bu

Summary Security workflows execute third-party GitHub Actions by mutable tags or a branch name. Evidence .github/workflows/security.yml:14-15, :52, and :62 use version tags. .github/workflows/ci.yml:354 uses aquasecurity/trivy-action@master. Why this matters If a referenced tag or branch is moved or an upstream action is compromised, repository workflows can execute changed code with workflow permissions. Full commit SHAs make the reviewed dependency immutable. Scope Pin every action in the security workflow and the Trivy scan step to verified full commit SHAs. Keep a trailing comment with the human-readable release and preserve automated update support. Acceptance criteria Every in-scope uses: reference is a 40-character commit SHA. Each pin has a release/version comment. The selected commits come from the official action repositories and match the intended versions. Dependabot configuration can continue proposing action updates. Workflow YAML remains valid. Verification rg -

Summary Core services log a full API key or the first ten characters of an invalid key. Evidence services/websocket_client.py:577-581 includes the dictionary key (the API key) in a close-error message. restx_api/option_greeks.py:116 logs the first ten characters of an invalid key. restx_api/multi_option_greeks.py:106 repeats the same prefix logging. Why this matters API keys should never be recoverable from logs. Prefixes can still be sensitive and can help correlate or enumerate credentials. Scope Remove key content from these messages. If correlation is necessary, use a short one-way diagnostic fingerprint with a documented domain separator, or log only that a key was present. Acceptance criteria No full or partial API key is interpolated into a log message. Different client-close failures remain distinguishable without key material. Invalid-key requests keep their current HTTP response. Tests capture logs and assert that dummy key content never appears. Verification uv run p

Summary Multiple non-XTS integrations log complete tokens, token prefixes, OTP request bodies, headers, or credential-bearing responses during authentication and funds requests. Evidence broker/fivepaisa/api/auth_api.py:63-90 logs token requests and responses. broker/mstock/api/auth_api.py:116 and :258-272 log tokens, headers, OTP/request data, and raw responses; broker/mstock/api/funds.py:24 logs a token prefix. broker/groww/api/funds.py:16 logs the auth token. broker/flattrade/api/auth_api.py:24-30, broker/dhan/api/auth_api.py:41,103,118, broker/paytm/api/auth_api.py:43, and broker/kotak/database/master_contract_db.py:317 expose full or partial credential material. Why this matters Logs are often retained, shared for support, and included in diagnostics. Redacting only part of a bearer token is not a safe substitute for omitting it. Scope Replace credential-bearing logs in the listed modules with safe status metadata. Keep broker response errors useful by selecting non-sensitive fi