Introduces the flat ErrorMessage envelope builder with BAPI_SEND_REPORT /
BAPI_SEND_TRACE gating (report/trace off by default), plus the design
spec and implementation plan for the consistent-error-responses work.
Fixes#148Fixes#123
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
sign_jwt added JWT_EXPIRY_TIME (seconds) to a milliseconds epoch and
stored it in a custom 'expires' claim, while register_cookie_updater
slept JWT_EXPIRY_TIME as seconds. With the code default (300) tokens
effectively expired almost immediately; with the sampled 3600000 the
cookie-refresh loop slept ~41 days, so the local .cookie held an
expired token nearly always. The custom claim also meant PyJWT never
validated expiry itself.
- issue standard 'iat'/'exp' claims (seconds) and let PyJWT validate,
requiring 'exp' on decode
- derive the cookie refresh interval from the same unit, guarded
against tiny/negative values
- default BAPI_JWT_EXPIRY_TIME to 3600s and fix .env_sample (was
3600000 'milliseconds')
Existing tokens and the local .cookie are invalidated by this change;
clients re-login and the cookie regenerates at startup.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This is a feature that allows to fetch the app status via a celery
task which stores the result in the Redis database and notifies the API
of the change. The API sends a notification to connected clients via the
SSE mechanism.
Using a background task allows to avoid crashing the whole API if the
script call fails.
The by default the cache is refreshed every 30 minutes. This can be
changed by setting the `BAPI_APP_STATUS_UPDATE_INTERVAL_MIN` environment
variable.
refs #123
If the environment variable BAPI_ENV_PATH is set, the config system will
try to read configs from the given path instead of .env in pwd
If no file is found .env in pwd will be used as a fallback
Env variables will always override settings in .env files.
Some remaining issues with current implementation:
Some remaining issues with current implementation:
* Some calls require shell access to lightning-cli as some gRPC calls are not yet implemented
* Getting on-chain fund flows is not as nice as it is with LND and required access to the Core Lightning SQlite database
* With current API you can only get current outputs
* High probability of bugs arising
closes#45
To keep Blitz API platform independent two code paths have been
implemented. A new "platform" .env variable must be set if running
on a raspiblitz to fetch hardware data from Redis. See the comments
in .env_sample for further explanation.
This is only useful for application running directly on the Raspiblitz.
This will create a file in ~/.blitz_api/.cookie with a valid JWT token.
Local applications can use this to authenticate to the API without
having to ask for the password. This is similar to how Bitcoin Cores
cookie auth works.
* password_a must now be posted in the request body as a json object
* password is now read from the .env file instead of hardcoded
* password will be checked if it is min 8 chars
* one_time_password is not yet in use and optional
